0
Third-party software
management under BSD
Andrew Pantyukhin
<infofarmer@FreeBSD.org>
EuroBSDCon 2006
powered by the FreeBS...
First things first
The need for 3d-party software

●

Why do we require packages

●

The need for package management

●

W...
History Packages in UNIX
OS is an all-included bundle

●

"Users" must figure out how to "use" software

●

themselves
Sys...
History Packages in BSD
JKH committed pkg_install in 1993

●

JKH committed ports in 1994

●

{Net,Open}BSD snatched both ...
History Packages in Linux
Many PM systems appeared in 1993-95, including

●

RPM and dpkg
Portage came out in 2002

●

A m...
Current Status
Dozens of distinctive PM systems

●

Focus on binary and/or source packages

●

Automation of compilation-r...
FreeBSD ports
Make + shell

●

Multiple scripts in multilevel directories

●

Effective automation of common tasks and hac...
NetBSD ports
Good documentation

●

pkginstall framework

●

pkg options framework

●
OpenBSD ports
Fake build environment

●

Immaculate documentation

●

Options, flavors, multi-packages

●

New pkg_install...
Looking out of BSD
RPM

●

Dpkg

●

Portage

●

Other

●

Linux Core Consortium - Standard Base

●
Why bother?
Isolation has its benefits, but

●

No system alone proved to be able to reach even

●

modest qualitative/qua...
What's up?
Scalability

●

Resource management/customization

●

Dependencies, capabilities, functionality

●

User-side m...
What packages need
and what they provide
Other packages

●

Resources

●

Functionality

●
OS Resources
for packages
Disk space

●

TCP/UDP ports at different addresses

●

File name spaces

●

User/group names/id...
Appliances
Package + dependencies bundled together

●

Jail appliances

●

OS appliances

●

BSD-based hardware appliances...
Package-Provided
Resources
(SQL) Databases

●

Virtual Hosts

●

Client connections to an (antivirus) engine

●

On-screen...
Package-Provided
Functionality
Needed by users directly and/or required by other

●

packages
API-oriented, e.g. language ...
Install-/run-time
customization
Automation of installation tasks based on simple

●

user-made choices
Single interface to...
Multiple package
instancing
Many versions installed at one time for testing and

●

compatibility
Several instances of the...
More flexibility
Movable packages - at post-install time

●

Non-privileged management

●

Per-user/per-jail package maski...
Versioning
Easily accessible older versions

●

Depending on older versions

●

Keeping distfiles in a VCS repo

●

Increm...
Getting pristine sources
RCS, VCS repositories

●

P2P

●

Metalinks

●

Rsync

●

Guided non-distributable downloads

●
User Interface
Centralized management

●

Orthogonal switches

●

Advanced on-line help/hints system in addition to

●

ma...
User Package Sets
Storage of package sets, easy access/distribution

●

Marking packages as requested or depended on

●

M...
Technicalities
distcc

●

ccache

●

Cross-compilation

●
Security
CVE is a dictionary

●

We need a database

●

Different projects use CVE/database as an overlay

●

Or, the data...
Exchanging hacks
Thousands of hacks spread out throughout the PM

●

systems
Only a few are documented, most of the other ...
Collaboration(ism)
Education

●

Spirit

●

Communication

●
Education
Other PM systems exist, and they do work

●

Many of them have good documentation

●

Behind projects there are ...
Spirit
No single PM system dominates the market

●

Rich traditions of forks and new-from-scratch solutions

●

gave us di...
Communication
Actual developers making contacts

●

Looking for solutions (in)

●

Sharing our ideas (out)

●

Taking part...
What's next
More forays into the wild

●

Mentioning the diversity of PM systems in docs

●

Learning from others

●

Brin...
Upcoming SlideShare
Loading in...5
×

Third-party software management under BSD

117

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
117
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "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 ●
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×