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. History Packages in UNIX
OS is an all-included bundle
●
"Users" must figure out how to "use" software
●
themselves
SysV/SunOS PKG format
●
4. History Packages in BSD
JKH committed pkg_install in 1993
●
JKH committed ports in 1994
●
{Net,Open}BSD snatched both of them
●
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. Current Status
Dozens of distinctive PM systems
●
Focus on binary and/or source packages
●
Automation of compilation-related routines
●
Automation of installation tasks
●
7. FreeBSD ports
Make + shell
●
Multiple scripts in multilevel directories
●
Effective automation of common tasks and hacks
●
10. Looking out of BSD
RPM
●
Dpkg
●
Portage
●
Other
●
Linux Core Consortium - Standard Base
●
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
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...
●
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
●
19. Multiple package
instancing
Many versions installed at one time for testing and
●
compatibility
Several instances of the same version with different
●
configurations
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. 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
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. 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
●
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. 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. 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. 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
●
