[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Getting rid of circular dependencies

"John H. Robinson, IV" <jaqque@debian.org> writes:

> Goswin von Brederlow wrote:
>> Or a "Package-Type: application | lib | data | doc | dev | common |
>> dummy". A yes/no field is hard to extend to more cases.
>> 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.

For aptitude the dummy package would just become automatic while the
package(s) the dummy package depends on should become the state the
dummy package was before the upgrade.

The dummy package would then get removed when nothing depends on it.

> Do aptitude/debfoster/deborphan use the same database for metadata? Is
> there any way that they could? Would this even be wise?

No. Not yet? It certainly would be nice if they could.

> 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.

It would solve the problem of abusing Depends to get packages removed
automaticaly when one of a pair gets removed.

> 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?

Having apt/dpkg refuse to install those (warn about it for a while
first) will clean those up quick enough.


Reply to: