packaging system (was: Re: GCC 3.3.2 kernel)

[Emiel Kollof]

* Lewis, Todd (todd.lewis at xxxxxx) wrote:
> 0) I agree that whatever is done, packaging everything (which openbsd
> apparently does, but which most linuces do, too) is a must-do.

Hmmhmm, agreed.

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

Yah well... Guess that makes me an old-timer then :)

> 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.

Why? The way it happens now is that "default" config files (ones that
were included with the source) are dumped into $LOCALBASE/etc and the
luser can RTFM and play with the examples. It's not like binaries are
dumped somewhere and the user is left alone. There is still
documentation in $LOCALBASE/share/doc, manual pages, and of course the
example configs in the etc dir. 

You see, BSD isn't Linux. Linux like to take the "user friendly"
approach and do everything for the user. In the BSD world it's customary
to read the manual and figure out how you get it to work. 

Sure, I wouldn't mind an automatic config system, but it's important
that it can be turned off and doesn't force itself down your throat.

> 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.

Well, the main problem with most (if not all) config management
approaches is that they can break, and when they do, all hell breaks
loose.

> (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.

I never needed a configuration management system on the operating system
itself to manage mass rollouts. A big upgrade here where I work just
gets done with packages pre-built by a dedicated build-box, which get
pushed (with a little help from ssh's remote execution). As for
configuration files, I use a central repository to manage those. 

Sure, it's a little work to set up, but I don't get paid to be lazy. Now
updating several hundred boxes at once takes just a few minutes of my
time.

> 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.

Huh? I don't want the package manager to touch my hand-tweaked
configuration files. Sure, you can put that in, but make it a toggle.

> 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.

Yes I dislike the split. Because it gets it my way. And I'm not alone.
What can header files hurt? It's not like the user ever sees them. And
embedded developers can just find / -type d -name include -exec rm -rf
{} \; if they want to get rid of them. Heck, you can include the headers
in the package, but _not_ install them. Also, since header files are
basically plain text, they compress pretty well too.

> 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.

With by hand, I mean the services _I_ have in place to manage my
configurations (and FYI, I administer quite a lot of FreeBSD machines in
my network (think several dozens) ). If I hate one thing, it's kludging around 
a package manager that sometimes blows away my changes. 

That doesn't take away that I think it's okay, just as long as it has an
'off' knob that never switches to 'on' when I don't tell it to.

> 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.

BSD already has a fixed hierarchy. See hier(7). Everything
with respect to system design is documented in manual pages. That's the
BSD way. It has been like that for ages. Nothing new. BSD has policy
everywhere. Browse around section 7 of the FreeBSD manual pages and get
enlightened.

> - 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.

Which is my big nitpick, since you don't have a choice. As long as it
has an off switch, I don't really care.

> - 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 current packaging system already documents both build- and running
dependancies. Portupgrade (available as a port) does exactly this. But
it's not part of the base system, and it has a 'weird' dependancy
(ruby). Also, portupgrade can get pretty fragile. 

> - 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.

The current packaging system doesn't really need it, since ports solve
that problem so well.  We need something like this as well for the new 
system. 

Old ideas aren't necessarily bad ideas, y'know :)

(Yeah I know I'm critical, but I'm trying to be constructive here.)

Cheers,
Emiel
--