Packaging system effort

Josh Elsasser jre at vineyard.net
Thu Feb 26 08:46:23 PST 2004


On Thu, Feb 26, 2004 at 01:36:43PM +0100, Simon 'corecode' Schubert wrote:
> My current knowledge concerning packaging systems is rather limited to 
> Debian's
> dpkg, FreeBSD's ports, NetBSD's pkgsrc and Gentoo's portage. As of such 
> I'll
> only reference to these systems for comparison with the One True System 
> (OTS)
> I'll describe here.

You may also wish to look at darwinports (darwinports.opendarwin.org)
for comparison.  It was available for freebsd and darwin/macos x last time I
checked.

> A very strong must have is a unified package flags system.
> [snip]

One minor thing I would like is for it to be very easy to view
available flags, eg without reading the Makefile like in ports.  One
nice thing the SCons build tool does is show available build options
and short descriptions if you say scons -h:

$ scons -h
scons: Reading SConscript files ...
scons: done reading SConscript files.

debug: Enable debugging when compiling (yes|no)
    default: 1
    actual: 1

readline: Enable readline support (yes|no)
    default: 0
    actual: 0

compiler: Compiler to use (cc|gcc|gcc-c99|icc|icc-w2)
    default: gcc
    actual: gcc

Use scons -H for help about command-line options.

> Debian's way of providing -dev packages which have been splitted off is 
> always a
> highly controversial point of discussion.
> [snip]

I have an inherent dislike of -dev packages myself, but can see how
something like that would be desired.  Perhaps a standard NO_HEADERS
flag is best.  But then how to handle if you later need the headers to
compile some other program...

Ok, this might be more trouble than it's worth, but how about the
ability to take certain files that don't need to be compiled (ie:
documentation, headers), and make their installation conditional on a
flag (NO_DOCS, NO_HEADERS).  The tricky part is that you have a very
easy (also automated, for if another port requires it) way of going
back, installing the header or doc files, then adding those files to
the plist and flipping the NO_HEADERS flag.

Basically, I'm proposing a quick way of later certain flags like
NO_HEADERS off after installation, and allow this to be used to not
install header files until they are needed.

This could aos be done by just having a seperate -headers port for
every single library and such, but that seems ugly to me.

> If possible, a nice addition would be the optional integration of 
> installation
> and build management of the base system.
> [snip]

I would not like to lose the distinction between base and ports.  One
thing that has always disturbed me about many linux distributions is
how the package system installs things into /usr instead of
/usr/local.  For linux this makes some sense, as your average linux
distribution is just a bunch of packages anyway.

Another minor thing, although this may be too early to bring the point
up.  I would like it if the package system didn't use /usr/local, like
netbsd and /usr/pkg.  This makes it easier to keep software installed
outside of the package system (yea, yea, I know.  You just need to do
it sometimes though) separate.  Plus, this will help insure that all
the packages respect PREFIX and aren't really just installing into
/usr/local.


Overall, I like the system you've presented, but I don't envy you
trying to actually implement this beast :)

 -jre





More information about the Kernel mailing list