here's the output of a birds-of-a-feather session at this year's LISA. it's about package management, and even though i couldn't attend myself, i got the notes for it and know some people involved. i thought it might be helpful to debian... package management BOF - talking a lot about configuration management and package management. - purpose: what should the scope of package management? - what are the areas in which you'd like to see package management improve? - suppose that I want to do work on a package manager. What should I work upon? Definition of a package manager: - Grayton Dobson: personal peeve: RPM. - rpm wants to play with tarballs. - unpack, pack, unpack. - redhat wants a simple way of saying "what's the current version of BASH?" - rpm is for cranking out rpm's [for RedHat's purposes]. - I'm using it because it's easiest to leverage an existing manager. - I can then only worry about what packages to run - As a code builder I want to do an RPM diff. - Deficiencies in process of creating a package - RPM is not a package manager; it's a release system. - It's a way for RedHat to distribute versions easily. - I want to turn something into something I can give someone to reuse. - Mandrake trying to rebuild bash, or a user with a new tool, here's an rpm, which implies a release tool. One of the reasons why package management and releases have been separate issues is that .... Paul Anderson: - important things about package manager is the amount of software that is available in the format - what's good about rpm is that a whole machine can be in described in that format. - not so easy to do in Solaris because there are different package formats on the same machine - meta-package-manager creates an abstraction layer that reports package lineage of software created by different package systems. Mark: - what are the problems? Paul Anderson: - dependencies are important, and dependencies aren't easy to resolve problems across different package managers? Mark - How many people are satisfied with the way that their package manager handles dependencies - A: no one. Heather Sherman: - what is the point of package management? A: - dependencies - uninstall - Inventory - conflict resolution Mark: I don't want to write the word "configuration" on this worksheet. I think the original reasoning for package management was to remember which files go with which package. The post-install came about much later, and the logic was that if one needs a default configuration, one does this in the post-install script. Paul Anderson: Post-install scripts are intended for situations in which a configuration manager isn't in use. Grayton Dobson: biggest problem is that post-install scripts are scripts, and can do anything, including reformatting the hard disk. Old days of solaris: monolithic install. More package management attributes: - trust - granularity - consistency. The inventory is not completely useless even if you have locally installed stuff, because you at least know the source of a file. In the last year, much source has contained trojans. If there is not a verification by signature, trojans are easy. init.d style configurations avoid awkward post-install scripts. Andy Davidoff: files are more atomic than the contents of files. Heather: we do service management, and web service. We build tarballs and allow configuration files to be put inside them. Unpack and you have a website. We package services this way and can unpack them and compile them for service management. Paul Anderson: binary packages are built for the environment in which they're compiled, not the environment on which they'll run. Dependencies should be clearly stated. Garrett Wollman: when compiling from source, packages will bind into arbitrary libraries, so that hidden dependencies occur. If repackaged, it'll bind to possibly non-existent libraries. Heather: wigwam.sourceforge.net [lost context] Mark: I try to minimise these bindings by ripping things out of paths. Grayton Dobson: build process has to lock down environment hard. We have three compilers for all builds. a) compiler for the platform on which compiler is being run b) cross-compiler for target architecture c) compiler for user who may be running this code. Autoconf assumes that you're not doing a cross-compile; that your current environment is your run environment. Almost anything that calls configure needs to be watched with care. Mark: what will you be happy with? Grayton - give a list of files that it wants to install. Paul - give a list of files that it depends upon. Andy Davidoff: Still have to create a map for software that is used by packages. Got to specify the environment that the thing requires (at 'configure' time). /usr/local is pretty common to use. Let's look there as well. Idiots! Need a clean and simple stripped machine. Garrett: when you as a normal human, not an administrator of the built cluster, want to build a new package, you can't because you don't know the assumptions under which the original packages were built Garrett: the sort of problem I'm been describing is that the packages were all from the same source, but they presumed that there will only be five things depending upon something rather than th 15 you have. Mark: We're treading into the "autoconf sucks" debate. We have an install script that will invoke configure with a bunch of arguments, so the options might be right on the machine that wrote the specfile, but wrong elsewhere. Difficult to create a reasonable package. Grayton: I write bash, I distribute the source, then you're going to run it on the computer on which it's compiled upon. With packages this is different. Mark: Identified lots of problems with package creation. Let's take off our package creator hats and put on our package user hats. Alva: in the case where one is making custom machines, and cannot afford to test rollouts, post-install scripts make it difficult to analyze potential installation failures. Mark: intent is to configure the thing after it's installed. Grayton: the purpose of post-install scripts is to do things the package manager can't do. The things you have to do and can't do anywhere else. What can we do about this? Paul: These sort of things are part of configuration, not part of installation Mark: What about using a macro-language to Andy: These things are really what cfengine was supposed to do. But cfengine somehow fails to do it. Mark: What I'm trying to do is a bit simpler. You say "adduser" and pass a couple of parameters, and a pattern is invoked that changes site policy. This is an abstraction pattern. Paul: it would be really interesting to analyze what is in the post-install scripts. -- .''`. martin f. krafft <madduck@debian.org> : :' : proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system
Attachment:
pgpGgkJCWsN6L.pgp
Description: PGP signature