Re: Back to RedHat

[David Engel <dlengel@home.com>]

On Fri, Sep 25, 1998 at 09:56:56AM +1000, Craig Sanders wrote:
> the pre-selections thing allows you to select multiple sets. it's a
> good system...the only reason i don't use it is that i have been using
> dselect for years and prefer to (tediously and painstakingly) select
> each individual package - that way i get exactly what i want, nothing
> more and nothing less.
> 
> i.e. the pre-selection thing is a short cut, dselect is more of a
> "precision tool". :-)

I disagree about pre-selections being a good system.  They are a
one-time only shortcut at initial installation.  They do nothing to
help a non-expert/non-power user maintain a system over time.

I like much better a couple of ideas I've mentioned before but have
gone largely ignored.  

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.

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?

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.

David
-- 
David Engel
dlengel@home.com