Re: Getting rid of circular dependencies
Goswin von Brederlow wrote:
> Russ Allbery <rra@stanford.edu> writes:
>
> > Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
> >
> >> But that doesn't realy solve the problem on its own. It would be nice if
> >> packages could be consistently taged with "Application:
> >> yes|no|<untaged>" signifying that this package is usefull on its own
> >> (foo), will never be used alone (foo-data, libfoo) or is
> >> ambigious. Frontends should then hide anything with "Application: no"
> >> under normal operations.
> >
> > This is a really interesting idea, particularly if it were combined with
> > an implementation recommendation to stop suppressing Application: no
> > packages if they're listed in Suggests of an installed package or list an
> > installed package in Enhances. That way, documentation packages could be
> > listed in Suggests but otherwise be Application: no, since the sort of
> > user who doesn't want to see all the library packages is probably also not
> > going to want to browse the list of documentation packages for packages
> > they don't have installed.
>
> Or a "Package-Type: application | lib | data | doc | dev | common |
> dummy". A yes/no field is hard to extend to more cases.
I like this idea. Frontends can then display the useful set
(application, possibly doc) by default, and leave the others hidden. As
long as the frontends were configurable to display all packages, then I
will be happy.
I dislike it when things try to be smarter than me. I don't mind
helpful, but I do mind condescention.
> As a bonus the 'Package-Type: dummy" would be packages needed to
> handle package renames or replacements and can be savely purged on the
> next aptitude/debfoster/deborphan run.
This would be very useful, indeed. It would have to be careful that the
dummy pcakges were indeed not needed anymore. Sounds like more state in
the frontend.
Do aptitude/debfoster/deborphan use the same database for metadata? Is
there any way that they could? Would this even be wise?
While I do find the above idea very useful, how does it help with the
circular dependency issue? Could there be another tag
``In-Case-Of-Circular-Dependecy-Install-Me-First: True'' ? This would
help in the case of *known* circular dependencies, and it leaves the
thinking up to a human (or perhaps an autobuilder that has attempted
various means of installing the circularly dependent packages, and
determined a working method) instead of leaving it up to the client
system to guess.
I'd like to see a linda/lintian warning for such things. In the case of
application and application-lib built from the same source, this is
easy. When you have applications outside of the source package, then it
would get a bit tougher. Can linda/lintian be extended to read the dpkg
database, to seek circular dependencies? Again, is this something
useful?
--
John H. Robinson, IV jaqque@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((
Reply to: