[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

	(echo x install; echo x-on-$HOME deinstall) | dpkg --set-selection


> 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?)


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: