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