> 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.
There are users that just want to have some toplevel packages installed. Ie. they want to have KDE + plus lyx for wordprocessing. So they just select a wordprocessing environment using a Graphics Environment. They don't want to be bothered from the start that they need some special version of Latex with fonts 'bla' and 'blo' and have the Xforms library installed. Also, If they choose for dutch locales, isn't it a logical choice you also install a dutch dict./wordlist and a dutch release of the babel pkg.? I agree with you in the fact we should not hide it if we want to see it. For myself, I want to finetune it. But I also want to be able to go back to some state that is preconfigured, most likely to work. Things should be more hierarchical more OO. > > 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. Back to my dutch KDE example. Say I want this real neat-o cool KDE graphics environment with dutch locales which is a standard preset option, and I decide I want to have ya old openlook olwm environment too, with other libs etc. It would check the dependencies for all the packages in this toplevel packages. If some dependency could not be fullfilled, just because portions of toplevel packages (lets call them software sets from now on) bite eachother should leave you to the choice of either resolving the breaks yourself by manually picking the right combinations and replace the biting ones, or just abandoning this toplevel choice, "sorry it's too much hassle for now". Hope this makes it clear... ;) Best regards, Pascal > -- Thorin Oakenshield > > ----- End of forwarded message from [EMAIL PROTECTED] -----