packaging system (was: Re: GCC 3.3.2 kernel)

[Lewis, Todd]

0) I agree that whatever is done, packaging everything (which openbsd
apparently does, but which most linuces do, too) is a must-do.

1) Ahh, the crochety-old-timer critique of dpkg.  8^)

I agree that config file management is an imperfect art, but the debian
system seems much better than "here's some binaries, good luck!" approach of
the simpler systems, especially in the face of thousands of packages on a
system.  Dpkg gives you plenty of tools to get your config files looking
like you want them to look, but without burdening you with bothering about
crap you don't care about.  Your critique strikes me as solipsistic; just
because they investment/return payoff isn't worth it to you doesn't mean
that it's not worth it to other people.  It's certainly been worth it to me
over the years, and I don't think that you understand how easy it is with
debconf to allow you to control your configs if you want, and therefore I
think that your criticism is overstated.

2) To my mind, for your criticism to be serious, you have to look at the
various problems that debian's config mgmt approach solves and explain them
away as unimportant or poorly done by dpkg or not worth the cost.
(Optional) automated system config allows the addition of software to the
system at near-zero marginal cost, which definitely aids users; it also
greatly facilitates automated deployment, which is crucial for large server
farms or for large sets of appliance or embedded machines.  I've used dpkg
in both environments, and it sped up the upgrade process by a phenomenal
amount.  Both times we cared very much about what our config files looked
like, and we managed them within dpkg, to great success.

3) Having the package manager involved with config file formats allows the
packaging system to deal easily with format changes and handle them safely,
which is a huge deal.

4) You dislike the package/package-devel split?  Are you kidding me?  You
would inflict header files on people building embedded systems because
you're too lazy to add a package name to your dependency list?  This is,
again, a little egocentric.

5) To return the flame bait, it's easy for small-time admins to
underestimate how important these issues are when your talking about
hundreds or thousands of machines.  "I like controlling my config files by
hand" is fine when you're running a few machines, but for large-scale
deployments, you want tools to help you, and you don't want to have to write
them yourself, and in this case they need to interact with the packaging
system intensely anyway.  This to me is a prima facie case for config file
handling in the package system that, if not identical to dpkg, is at least
similar in scope.

6) I'm not arguing for dpkg as a format; I'm not arguing for anything, not
least because I'm not actually involved in the dragonflybsd project, other
than as an interested observer.  But those who do not study the past while
mistakenly criticizing it are doomed to etc. etc.

Here are a few more dpkg items that, to my mind, should be studied by people
interested in working in this area:

- the policy manual is a work of art.  What is beautiful about it is not the
particular policy decisions enshrined in it: tastes certainly differ, and
many good admins disagree about file layout, etc.  What is beautiful is that
the debain folks made decisions, documented them extensively, and then
maintained and strenghthened them over the years in response to their
experiences, and they did this for a very wide range of issues that affect
packaging decisions.  Say what you want about dpkg's, but there's little
doubt when you're building one what policy they should follow.

- the fact that the entire system, soup-to-nuts, is dpkg-managed.  With
this, I can track all files back to the package, and therefore back to the
source, from which they originated, and do so with a single command.

- documenting build dependencies is awesome, especially when combined with
apt.  This was the one thing that drew me to /usr/ports over the years, but
now rebuilding with dpkg is just as easy, and I don't have to give up all of
dpkg's features.

- the tool suite to build packages, debhelp & its successors.  These make it
really easy to slap a package together, have it work well within the system
(meet policy, etc.), and then tweak the package as you get experience with
it.  By creating a common vocabulary, instead of 10,000 flavors of makefile,
it makes it easy to open up most source dpkgs and immediately understand
what they're doing.

There are more, but I'll go back to work and let others discuss.

-----Original Message-----
From: Emiel Kollof [mailto:coolvibe at xxxxxxxxxxxxxxxx] 
Sent: Thursday, October 30, 2003 12:34 PM
Subject: Re: packaging system (was: Re: GCC 3.3.2 kernel)


* Lewis, Todd (todd.lewis at xxxxxx) wrote:
> Emiel Kollof wrote:
> 
> > I agree. I for one, don't like dpkg.
> 
> Why not?  The more details, the better; I'm really curious.

Dpkg is typical GNU stuff: overfeatured, obtuse and too complex[1]. It does
waaaaaay more than a package format needs to do. Things that irk me about
dpkg are for instance the configuration phase. I'd like to do that myself,
thanks. I don't want dpkg to manage my configfiles for me. Also, the nasty
habit of splitting up apps in their use and -devel counterparts is something
I despise.

The big question is: why should we move to a new file format for packages? 

As far as I care, the current BSD packages are fine as they are as packages,

but the managing of those packages (/var/db/pkg, portupgrade, etc etc) needs

to be overhauled. This is where we could use something more
apt/portage-like. Add variant symlinks and VFS magic in the mix, and we have
something partly 'backwards'-compatible and beautiful :)

Also, since we still have FreeBSD binary compatibility, wouldn't it be nice
to be able to use FreeBSD's already compiled package repository? Why should
we move to a whole new package format? As far as simplicity goes, the
FreeBSD package format (.tgz) is as simple[1] as it gets.

> Everyone knows the 1001 ways in which dpkg/apt/debian rock, right?  If 
> not, then I'd be happy to list them...

Most of the people that proclaim the virtues of Debian, are talking about
apt, not dpkg. And they both get confused with each other all the time. .deb
is the package format. apt is the package management. 

Apt is nice and package-format agnostic (which is mainly why it's nice).
dpkg 
sucks since it's (to me) unwieldy.

Sure, we could steal a couple of nice ideas from apt (like the binary
upgradeability), but do we really need a totally new package file format?

Cheers,
Emiel

[1] With "simple" and "complex" I don't mean ease of use.
--