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


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 developers feedback from the point of view of a user who doesn't have commit rights.

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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

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