Debian package system proposals [was: Re: Back to RedHat]
David wrote:
> The first idea is to have, for lack of a better name, super packages.
> Super packages don't contain any files. Instead, they only contain
> dependencies on other packages. The advantage is that the desired set
> of packages can be changed by simply modifying the dependency list in
> the super package.
Such packages are completely possible today, as far as I understand it. It
would be most useful if you could put an example together: this could serve
to test whether the advantage outweighs the disadvantages (incurred by
extra maintenance, created unresolvable conflicts etc.)
You are right that this is an old idea: I remember it from '93 before Ian
decided to write the Debian package system in Perl (Once And For All :)...
> The second idea is for dselect (or apt or whatever) to either
> automatically or at least offer to remove packages which haven't been
> explicitly selected by the user when no other installed packages
> depend on them. Anyone have a good name for this. The advantage is
> that the user doesn't have to tediously keep track of packages that
> are no longer needed. How many times have you wanted to try out a
> package only to find out that it installing it pulls in several other
> packages, then later decide you don't want/need it, go to deselect it
> and not remember all the other packages it pulled in?
What is needed to do this is to be able to distinguish between packages
that are "actively" and "passively" selected. With such a classification I
agree it would be useful with a command to unselect passively selected
packages when no other packages depend on them. One could then by default
always select libraries passively, for example.
> Here's a real world example of how the above ideas could work. The
> preferred libstdc++ development package recently changed from
> libstdc++2.8-dev to libstdc++2.9-dev. With the current pre-selection
> system, a user who is using hamm would have libstdc++2.8-dev
> installed. When that user upgrades to slink, he has to notice that
> libstdc++2.9-dev is now available, decide that it is preferred over
> libstdc++2.8-dev, explicitly select libstdc++2.9-dev and then
> explicitly deselect libstdc++2.8-dev to resolve the resulting
> conflict. In contrast, a c++development super package which changed
> from depending on libstdc++2.8-dev in hamm to depending on
> libstdc++2.9-dev in slink would automatically handle the replacement
> of libstdc++2.8-dev with libstdc++2.9-dev.
Good example: I propose you try it and let it loose in slink!
Cheers,
Kristoffer
--
Kristoffer Høgsbro Rose, Ph.D., prof.associé <Kristoffer.Rose@ENS-Lyon.FR>
Laboratoire de l'Informatique du Parallélisme équipe PLUME, bureau LR5-026
Ecole Normale Supérieure de Lyon; 46, Allée d'Italie; F-69364 Lyon 07 cedex
phone: +33(0)4 7272 8642; fax:...8080 <http://www.ens-lyon.fr/~krisrose>
Reply to: