New dselect project
> 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 MAILER-DAEMON@debian.novare.net -----
Reply to: