Your SlideShare is downloading. ×
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
From the trenches: experiences from a user's point of view
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

From the trenches: experiences from a user's point of view

541

Published on

A very personal summary of experiences using pkgsrc during the last year as a user. Christoph will highlight things pkgsrc does well and things which it does not so well. The aim is to give the …

A very personal summary of experiences using pkgsrc during the last year as a user. Christoph will highlight things pkgsrc does well and things which it does not so well. The aim is to give the developers feedback from the point of view of a user who doesn't have commit rights.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
541
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. From the Trenches Christoph Badura pkgsrcCon 2007
  • 2. Introduction
    • We put lots of effort into improving pkgsrc technically
    • But don't talk much about our user's needs
    • Tell about my experiences and thoughts about the matter
  • 3. A bit of background
    • Pkgsrc user and NetBSD developer since late 90s
    • Spend lots of time on business travel in the last years
    • Use NetBSD on laptop for day-to-day work
  • 4. Background (cont.)
    • Limited time to work on NetBSD
    • “pkgsrc user” with “commit bit”
  • 5. Usage at company
    • Have some mission critical servers running NetBSD
    • Usually “install & forget”
    • Admins not expected to update perfectly working systems
    • Old NetBSD branches (2.x until recently)
    • Old pkgsrc trees
  • 6. Who are the users?
    • Hobbyists
      • Students
    • “business” users
      • Sysadmins
      • Consultants
  • 7. What the users want
    • Install working software with minimal effort
  • 8. Pkgsrc developers vs. Users
    • Developers spend lots of time on
      • Improving the pkgsrc infrastructure
      • Maintaining packages / fixing bugs
    • Constantly changing system is OK for them
    • Do not necessarily use the software they maintain
    • Neglect installation/update system
  • 9. Admins aren't SW-developers
    • Admins often have no formal CS training
      • Often have trouble compiling software
      • Low level of automation for system administration
    • Admins often build machines manually
    • Automation using YaST or similar installer
    • Often no automation for local packages/software
  • 10. SW-Developer's aren't admins
    • Have no concept of large scale system administration
      • Often have no understanding for doing system administration at all
    • Don't build machines
    • Think that their software materializes magically on production machines
    • Don't package their software
  • 11. Benefits of using packages
    • Show developers/admins that using binary packages is a good thing
      • Can move software easily between machines
      • Can automatically install identical machines
      • Have documentation what the state of a machine is
  • 12. Corp. users want stable environment
    • When you admin 600 servers you can't update them daily
    • Typically machines are “install & forget”
    • Only apply security updates
    • And fixes for bugs that affect production use
  • 13. People don't get paid to constantly update software
    • Management expects them to do “real work”
    • Risk of down time
      • In case updated software is buggy
      • Or not compatible
    • Quarterly pkgsrc branch is to short-lived
  • 14. Distribution life time
    • There's a reason why “enterprise” Linux distros are maintained for 3-5 years
    • Pkgsrc needs more “man power” to maintain branches longer
    • More a question of attracting “man power”
  • 15. Interacting with users
  • 16. How to get a usable system
    • Q: I know SuSE/Debian/Ubuntu/etc. How do I start the software installer for the packages on NetBSD?
    • A: ???
  • 17. How to update a system
    • Q: How do I update the packages on my system to the latest ones?
    • A: ???
  • 18. Need a package manager
    • Users want something like aptitude/YaST
    • Easy selection of packages to install/update/deinstall
    • Actual installation/deinstallation done in batch mode
    • Keeps track what the user installed on system
  • 19. Working with PRs
    • Creating a PR takes time
      • Easily 15-30 minutes
    • Each PR likely means several users have the same experience
    • Only single person working on the PR
    • Closing a PR is “heavy weight” action
      • Can't be opened again by the user
      • Additional comments are easily lost
  • 20. Reasons for closing PRs
    • Didn't try to understand what the underlying problem is
    • Didn't understand what the user was trying to say
    • Making outrageous policy claims
      • Maintainer not interested in improving usability of pkg
      • Telling submitter to go away
  • 21. Bad defaults
    • /usr/pkg/xorg/bin
    • Extract xsets; rehash; xterm
    • Install xorg pkg; rehash; xterm
      • xterm not found
    • Both can't meaningfully coexist
  • 22. Renaming packages
    • Interferes with updating systems
    • “make update” fails
    • Automation fails because package lists get out of sync
    • Keeping package lists in sync between different environments
  • 23. Yearly package update
    • About 60 packages plus depends
    • Takes me about 3-5 work days
    • Just to get where I was before the update
  • 24. Version mismatch
    • Update NetBSD to new minor release
    • Install binary package
    • “this package was compiled for a different OS version. Consider yourself lucky if it works.”
  • 25. Developing packages
  • 26. Great build system
    • Bulk builds ensure that most of the packages actually build
    • Bulk builds ensure that we have lots of binary pkgs
    • Slower arches have difficulties keeping up, though
  • 27. Build machinery not separate
    • Individual package Makefiles still know to much about build machinery/other packages
    • Difficult to mix old and new versions of pkgsrc
  • 28. Package options
    • Better than under FreeBSD
      • Tends to pop up dialog boxes at inconvenient times
    • Bad for bulk building binary packages
      • Unless all options are selected
      • Otherwise binary packages end up with wrong option set
      • Postfix w/TLS/SASL anyone?
      • Need to build from source for common options
  • 29. buildlinking
    • How to create a buildlink3 file?
    • Need short explanation in the guide
  • 30. developing on slow machines
    • Getting stuck in clean/extract/patch/configure/compile cycle
    • Really tedious
  • 31. Troubleshooting compiler/buildlink issues
    • How to invoke compiler for a single source file?
      • Wrapper transformations
      • Env vars?
  • 32. Caching DEPENDS
    • Apparently caches DEPENDS info in WRKDIR
    • Editing Makefile requires clean/extract/compile cycle
    • Did I mention slow machines yet?
  • 33. Local customizations
    • How to maintain them?
    • patches/patch-local-??
    • How to do version control?
  • 34. Local packages
    • Can maintain them in pkgsrc/local
    • But need to keep in sync with rest of tree
      • Renaming of packages
    • RPM separates build and package creation infrastructure from package recipes
  • 35. Fin
    • Encourage those who want to contribute
    • A big thanks for providing pkgsrc
    • Thanks for listening

×