Re: Ignoring dependance on "important" packages?
Nathaniel Smith writes:
> About task packages: I've always thought that the best way to do a task
> package is _not_ with dependencies on all the various parts. This has
> many drawbacks, the main one being that it's totally inflexible.
Some things should not be done with dependencies but some should. There is
a hybrid of what you're suggesting that uses the package system that I
think might be interesting...
> For me, a task package should be just like any other package, except that
> it happens to install a script of some sort in /usr/lib/tasks or
> whereever would be appropriate. We also define some sort of way to
> communicate between this script and apt, or maybe we just have the script
> call apt-get directly; whatever.
The package system can be used for the communication: assume the task package
1. Depends: on what is needed to SETUP the task,
2. CREATES a new package "my-task" which Conflicts: and Replaces: the task
package and only Depends: on what is needed to USE the task as it has
been configured, and
3. installs "my-task" which automagically removes the original task
package.
For X, for example, the task/x package should
1. Depend: xserver-vga16 (or xserver-fb when it becomes available :) and
xf86setup and whatnot but no fonts etc. (yet),
2. create a package "x-on-$HOST" (or somesuch) which depends on xserver-s3
and the desired X packages and then stays in the system, and
3. finish (in its postins script?) by marking itself for deletion and the
"x-on-$HOST" package for installation (this is easy with a small script
like
(echo x install; echo x-on-$HOME deinstall) | dpkg --set-selection
sic).
> This script when run then will do whatever it needs to do to talk to the
> user and install the package.
This could happen in the postinst of task/x. That way we can exploit the
preconfiguration that is eventually designed to even preconfigure tasks!
> The best example I can think of for this is X. Trying to figure out what
> needs to be installed what with xserver-common, xserver-<your server
> here>, all the fonts (not Required:, but necessary for just about
> everyone), xfree86-common, xbase-clients, ... it's all very modular and
> nice, and allows you to do all sorts of different configurations with
> pure X terminals and everything, but trying to figure out which ones to
> install is fairly insane for a new user, and it's easy to miss something
> that you need.
I agree...and this fits perfectly in the modified scheme above.
And it has the advantage that *afterwards* the user cannot inadvertently
remove a package which is crucial for the task as configured. That would
require deinstalling the task. If it's configuration is not purged then
the next installation of task/x will use it...
(So there is a technical problem here: can a "Replaces:" package inherit
the configuration of the package it replaces?)
Best,
Kristoffer
--
Kristoffer Høgsbro Rose, phd, prof.associé <http://www.ens-lyon.fr/~krisrose>
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080 <Kristoffer.Rose@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <krisrose@{debian,tug}.org>
Reply to: