Third-party software management under BSD

427 views
270 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
427
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Third-party software management under BSD

  1. 1. Third-party software management under BSD Andrew Pantyukhin <infofarmer@FreeBSD.org> EuroBSDCon 2006 powered by the FreeBSD Foundation
  2. 2. First things first The need for 3d-party software ● Why do we require packages ● The need for package management ● What do we expect to manage ●
  3. 3. History Packages in UNIX OS is an all-included bundle ● "Users" must figure out how to "use" software ● themselves SysV/SunOS PKG format ●
  4. 4. History Packages in BSD JKH committed pkg_install in 1993 ● JKH committed ports in 1994 ● {Net,Open}BSD snatched both of them ●
  5. 5. History Packages in Linux Many PM systems appeared in 1993-95, including ● RPM and dpkg Portage came out in 2002 ● A multitude of PM systems were started over since ● 90s, some of them still maintained, some actively developed
  6. 6. Current Status Dozens of distinctive PM systems ● Focus on binary and/or source packages ● Automation of compilation-related routines ● Automation of installation tasks ●
  7. 7. FreeBSD ports Make + shell ● Multiple scripts in multilevel directories ● Effective automation of common tasks and hacks ●
  8. 8. NetBSD ports Good documentation ● pkginstall framework ● pkg options framework ●
  9. 9. OpenBSD ports Fake build environment ● Immaculate documentation ● Options, flavors, multi-packages ● New pkg_install + a hard-headed maintainer ●
  10. 10. Looking out of BSD RPM ● Dpkg ● Portage ● Other ● Linux Core Consortium - Standard Base ●
  11. 11. Why bother? Isolation has its benefits, but ● No system alone proved to be able to reach even ● modest qualitative/quantitative targets We have too much in common not to share ideas and ● code
  12. 12. What's up? Scalability ● Resource management/customization ● Dependencies, capabilities, functionality ● User-side management, interface, Clicks! ● Versioning everywhere ● Saving porter a lifetime (as in more automation) ● Much more... ●
  13. 13. What packages need and what they provide Other packages ● Resources ● Functionality ●
  14. 14. OS Resources for packages Disk space ● TCP/UDP ports at different addresses ● File name spaces ● User/group names/ids ● CPU, RAM, disk throughput, etc. ● Bandwidth ● You name it... ●
  15. 15. Appliances Package + dependencies bundled together ● Jail appliances ● OS appliances ● BSD-based hardware appliances ●
  16. 16. Package-Provided Resources (SQL) Databases ● Virtual Hosts ● Client connections to an (antivirus) engine ● On-screen pixel real-estate ● Technically specific items, like lines in configuration ● files
  17. 17. Package-Provided Functionality Needed by users directly and/or required by other ● packages API-oriented, e.g. language modules and extensions, ● binary libraries Task-oriented, e.g. web servers, mail clients, DBMS ●
  18. 18. Install-/run-time customization Automation of installation tasks based on simple ● user-made choices Single interface to configure the usage of some ● resources, like TCP ports
  19. 19. Multiple package instancing Many versions installed at one time for testing and ● compatibility Several instances of the same version with different ● configurations
  20. 20. More flexibility Movable packages - at post-install time ● Non-privileged management ● Per-user/per-jail package masking ●
  21. 21. Versioning Easily accessible older versions ● Depending on older versions ● Keeping distfiles in a VCS repo ● Incremental distfile updates ●
  22. 22. Getting pristine sources RCS, VCS repositories ● P2P ● Metalinks ● Rsync ● Guided non-distributable downloads ●
  23. 23. User Interface Centralized management ● Orthogonal switches ● Advanced on-line help/hints system in addition to ● manpages and other documentation Integrated updating capabilities ● Options handling ● Clicks ●
  24. 24. User Package Sets Storage of package sets, easy access/distribution ● Marking packages as requested or depended on ● Marking some big (sets of) packages as undesirable ● to be installed
  25. 25. Technicalities distcc ● ccache ● Cross-compilation ●
  26. 26. Security CVE is a dictionary ● We need a database ● Different projects use CVE/database as an overlay ● Or, the database stores info about projects ●
  27. 27. Exchanging hacks Thousands of hacks spread out throughout the PM ● systems Only a few are documented, most of the other ones ● are abandoned and forgotten Developers have to reinvent solutions ●
  28. 28. Collaboration(ism) Education ● Spirit ● Communication ●
  29. 29. Education Other PM systems exist, and they do work ● Many of them have good documentation ● Behind projects there are people to talk to and to learn ● from
  30. 30. Spirit No single PM system dominates the market ● Rich traditions of forks and new-from-scratch solutions ● gave us diversity, but prevent us from trying to work together Working with people/approaches we don't necessarily ● like
  31. 31. Communication Actual developers making contacts ● Looking for solutions (in) ● Sharing our ideas (out) ● Taking part in outside discussions ● Inviting outsiders over to our forums ●
  32. 32. What's next More forays into the wild ● Mentioning the diversity of PM systems in docs ● Learning from others ● Bringing in foreign solutions ● Standardizing on decisions ●

×