Your SlideShare is downloading. ×
0
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

550

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
550
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 <ul><li>We put lots of effort into improving pkgsrc technically </li></ul><ul><li>But don&apos;t talk much about our user&apos;s needs </li></ul><ul><li>Tell about my experiences and thoughts about the matter </li></ul>
  • 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. Background (cont.) <ul><li>Limited time to work on NetBSD </li></ul><ul><li>“pkgsrc user” with “commit bit” </li></ul>
  • 5. Usage at company <ul><li>Have some mission critical servers running NetBSD </li></ul><ul><li>Usually “install &amp; 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. 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. What the users want <ul><li>Install working software with minimal effort </li></ul>
  • 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. Admins aren&apos;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. SW-Developer&apos;s aren&apos;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&apos;t build machines </li></ul><ul><li>Think that their software materializes magically on production machines </li></ul><ul><li>Don&apos;t package their software </li></ul>
  • 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. Corp. users want stable environment <ul><li>When you admin 600 servers you can&apos;t update them daily </li></ul><ul><li>Typically machines are “install &amp; forget” </li></ul><ul><li>Only apply security updates </li></ul><ul><li>And fixes for bugs that affect production use </li></ul>
  • 13. People don&apos;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. Distribution life time <ul><li>There&apos;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. Interacting with users
  • 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. 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. 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. 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&apos;t be opened again by the user </li></ul></ul><ul><ul><li>Additional comments are easily lost </li></ul></ul>
  • 20. Reasons for closing PRs <ul><li>Didn&apos;t try to understand what the underlying problem is </li></ul><ul><li>Didn&apos;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. 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&apos;t meaningfully coexist </li></ul>
  • 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. 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. 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. Developing packages
  • 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. 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. 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. buildlinking <ul><li>How to create a buildlink3 file? </li></ul><ul><li>Need short explanation in the guide </li></ul>
  • 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. 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. 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. 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. 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. 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>

×