Task packages (was Re: Ignoring dependance on "important" packages?)
Apologies for the abrupt reply, but this seems to me to be overly complicated,
overly inflexible (what if the user wants to go back and install more? what
if they get a new video card and want to reprobe (in the X example)?), and
broken in terms of upgrades (what if the packages are reorganized?). Trying to
help prevent a new user from shooting themself in the foot is well and good,
but in this case 1) they shouldn't be removing packages that they don't know
what do _anyway_, and 2) it makes things harder for experienced users, who
want to customize one of the default profiles. Sure, they could use dpkg
--force-depends, but that breaks apt, or they could remove the task
package, but then you lose the power of having something like that to manage
upgrades and reconfigure. So, I don't like it (you probably figured that
out by now :-)).
-- Nathaniel
P.S.: If anyone was wondering, I am playing around with perl to create a
basic task management system. If anyone could give me a quick explanation
of how the profiles are handled during dbootstrap, I'd appreciate it (so
I can figure out better how to handle the interaction-free install).
Kristoffer: sorry if you got this twice, mutt doesn't do what I expect when
I hit reply on a mailing list.
On Wed, Jul 28, 1999 at 06:51:48PM +0200, Kristoffer.Rose@ENS-Lyon.FR wrote:
> 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>
>
>
> --
> To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: