Re: "dselect" replacement project ("deity")y
On Sun, 13 Apr 1997, P.A.M. van Dam wrote:
> > This is the real issue. If you could select the 'high level' groups
> > and only deal with the components if you want the option it would
> > be fine. But if I select a group I want it to mean 'install what
> > it takes to make this work', not 'tell me about some other things
> > I need to do first in some unknown order'.
> It would be really nice to have some highlever package order, like
> some commercial UNIX vendors have. For example one might have the choice
> to install everything as it suits himself or choose some highlevel packages
> like a KDE environment using Dutch locales or a OpenLook environent or just
> good old non-graphic install. It makes it much easier for newbies. We need
> some hierarchy in the package structures.
> > Les Mikesell
> > email@example.com
> Best regards,
I'm sorry to be dogmatic, but I'm going to say one more time that I like
things the way they are. If something depends on seperately maintained
library xyz it is not good but *GREAT* to know about it from the start.
The dependency structure sends this message to users load and clear, in a
way that a lumped package scheme would not even if a full description of
all dependencies were given when such a package was installed. I really
had no clue about the high level of software interdependence when I
started with slackware, and it hurt me continually. I think a little pain
with dselect in the beginning would have saved me a lot of grief later.
Lets give a more understandable dselect a chance. It could be made
infinitely more comprehensible. Am I right in thinking that when one
package you include during a 'dependence session' requires another
package, you get a new sort of recursive dependence session? I feel that
I shouldn't really have to be confused about this sort of thing.
I like six eggs when starting on a journey. Fried - not poached. And
mind you don't break 'em. I won't eat a broken egg.
-- Thorin Oakenshield