Re: Annoying package dependence concept
> Debian's realization of package dependencies is, in my opinion,
> too tight.
> Two (out of many possible) examples may illustrate my point:
> - A user doesn't want to install Debian's ghostscript since
> he is a ghostscript beta tester and has a newer version
> than Debian provides.
> However, since he wants to use previewers like gv, ghostview
> and xdvi (which depend on ghostscript) he MUST install the
> Debian ghostscript.
Xdvi dose not "depend" on ghostscript but "recommend" it.
> - A user wants to install ghostscript.
> Due to a dependence on "libpaper" which "doesn't seem to
> be available" this fails. Since previewers like ghostview
> and xdvi (why actually does xdvi depend on ghostscript ?)
> depend on this package the user is left with a system
> on which he cannot view .ps and .dvi files.
Here is where libpaper is:
> The basic problem is that deselect doesn't allow to override
> any dependencies specified by package maintainers. This, however,
> is necessary since package dependencies
> - may point to non-existing packages.
In my experience, this has not been the problem. Most of time I just
don't know "Where" that package is.
> - may not be reasonable (xdvi depends on ghostscript ?).
> - may already be satisfied by local software deselect doesn't
> know about.
This might be, but most people use all debian system. In which case it
works very well.
> It would already help a lot if deselect allowed the administrator
> to install a package as a "ghost" in the sense that:
> - the package counts as being installed as far as deselect
> is concerned.
> - deselect does not attempt to unpack/install the package.
Hmmm...interesting idea. But what happens when a new user uses this
feature and find errors when using a program. She/He would look at
dselect and think it is install when the package wasn't. Still it might
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com