How much added complexity in packages to cater for apt's shortcomings?
It is well known that apt has an issue when it comes to resolving circular dependencies. Therefore, Debian bug reporters have set out to eradicate circular dependencies from the archive. This does, however, add significant bloat to the actual packages, and I am questioning why this is really necessary.
For example, aide. aide has an aide-common package, depending on aide | aide-binary. aide-binary is a virtual package by aide, aide-dynamic, and aide-xen. All three providers of aide-binary depend on aide-common again, which is a circular dependency.
If I now follow the request posed in #545852 and remove aide-common's dependency on aide | aide-binary, I'll have to cater for the case of the aide-binary bein absent in each and every helper script included in aide-common, which would drive the script's complexity up to a new level. I really hate that idea.
Is it really necessary to work around apt's shortcomings by eliminating the case that apt doesn't handle well from the archive, and driving up other packages' complexity (and the possibility of bugs in this added complexity)?
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
Jonathan Nieder on :
Isn’t a dpkg shortcoming involved, too? For dpkg, a dependency is a statement about order of configuration: if aide-common depends on aide, then aide must be configured before aide-common can be configured. And vice versa.
So one of the two dependencies really must not hold. Probably the truth is: aide must be unpacked before aide-common is configured, and aide-common must be configured before aide can be configured. (Here “configured” means “ready to satisfy other packages’ dependencies”.) Unfortunately, dpkg does not provide a way to say that, and if you are unlucky then the result might subtly break other packages that depend on aide.
Marc 'Zugschlus' Haber on :
Probably.
With aide, the situation is a little easier since the binary packages do not have any maintainer scripts. So the only dependency is that the aide binary package needs to be present and unpacked before aide-common is configured. Things have been like this for years in aide and I haven't heard of any trouble.
Jonathan Nieder on :
In that case, as Joey implied, the circular dependency should be fine. I agree with you that obfuscating aide-common to avoid one is not a good idea.
Thanks for the interesting example.
Jonathan Nieder on :
Just to be explicit (to help people of the future who may read this):
The dpkg problem is documented in policy §7.2: [1]
| In case of circular dependencies, since installation or | removal order honoring the dependency order can't | be established, dependency loops are broken at some | point (based on rules below), and some packages may | not be able to rely on their dependencies being present | when being installed or removed, depending on which | side of the break of the circular dependency loop they | happen to be on.
So in general, a circular dependency can be dangerous...
| If one of the packages in the loop has no postinst | script, then the cycle will be broken at that package, | so as to ensure that all postinst scripts run with the | dependencies properly configured if this is possible. | Otherwise the breaking point is arbitrary.
... but in this case, it is not.
The only reasons left to care are complication and that reference-counting tools looking for leaf packages to delete can have a hard time finding the cycle.
[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
Jonathan Nieder on :
In parent comment, I said this circular dependency is safe.
But my reasoning is wrong.
The unspoken assumption: if a package outside a dependency loop depends on a package in a dependency loop, it will wait for all packages in the loop to be configured before running its postinst. Looking at the source, I’m pretty sure that assumption is just wrong. Agh!
So there’s an idea for improving dpkg without adding any dependency fields.
Sorry for the nonsense.
Jonathan Nieder on :
On second thought: maybe the aide binary could be moved to a new aide-bin package and aide become an empty package with Depends: aide-bin, aide-common.
Ugly, but I think it would work.
As for the question you asked --- um, probably no?
Marc 'Zugschlus' Haber on :
There are three packages providing an aide binary. The default package (the one without the suffix) has a statically linked binary as recommended by upstream, aide-dynamic has a dynamically linked binary as requests by some users (at the expense of a significant security risk), and aide-xen is IIRC patched to be a better neighbor on xen guests.
I don't see whether your suggestion is going to help with the situation.
Jonathan Nieder on :
I was imagining something like this:
aide - Depends: aide-common, aide-static | aide-binary aide-static - Recommends: aide, Provides: aide-binary aide-dynamic - Recommends: aide, Provides: aide-binary aide-xen - Recommends: aide, Provides: aide-binary aide-common - Depends: aide-static | aide-binary
But really, the churn alone would not be worth it. I was imagining a situation worse than it is.
Marc 'Zugschlus' Haber on :
Wouldn't work. Imagine somebody installing aide-dynamic without recommends, who would end up without aide-common.
Jonathan Nieder on :
Yes, it would silently break on upgrade. Forget I said anything. sigh
(Here is the ugly workaround for that:
aide - Depends: aide-common, aide-static-bin | aide-binary aide-static-bin - Recommends: aide, Provides: aide-binary aide-dynamic-bin - Recommends: aide, Provides: aide-binary aide-xen-bin - Recommends: aide, Provides: aide-binary aide-common - Depends: aide-static-bin | aide-binary
aide-dynamic - (transitional package) Depends: aide, aide-dynamic-bin aide-xen - Depends: aide, aide-xen-bin
Surely this is not worth it.)
Marc 'Zugschlus' Haber on :
That would still leave people installing aide-dynamic-bin without recommends without an aide-common.
Jonathan Nieder on :
Yes, that is by design. Similarly, vim-common does not depend on vim, libgtk2.0-common does not depend on libgtk2.0-0, and openssh-blacklist does not depend on openssh. The main downside is that people with aide-dynamic-bin but not aide-common installed might be tempted to run aide and find it broken; to fix this, one could install the binary to /usr/lib/aide and install a symlink in /usr/bin in the aide-common postinst.
Jonathan Nieder on :
Or, better, the aide postinst.
Do you actually want to do this? (If so, I’d be glad to look at the package and try modifying it accordingly. I’m still unconvinced it is a good idea.)
Marc 'Zugschlus' Haber on :
This is already done with a wrapper in aide-common.
Marc 'Zugschlus' Haber on :
Aide is a security tool. I hate the idea of having people with an inoperable aide because of a dpkg shortcoming.
Corsac on :
And why exactly does aide-common depend on aide | aide-binary? Can't the dependency been dropped or switched to a Recommends?
Marc 'Zugschlus' Haber on :
Because the scripts coming with aide-common are much easier if they can rely on the fact that there is an aide binary available.
Only by adding additional complexity to aide-commons's scripts which need to check whether there is an aide binary available and handle the "not available" case gracefully. This is exactly the situation I'd like to avoid.
Joey Hess on :
It's perfectly fine to have circular dependencies if you are aware that dpkg has to break the loop somewhere to configure the package, and you handle that properly.
IIRC, dpkg chooses to break dependency loops at packages that have no maintainer scripts. Thus, your aide-binary packages will be configured before aide-common is configured, and, presumably, nothing will break.
Bill has been filing scattershot circular dependency bugs for years. I assume he does this because he thinks that analising, dealing with, and avoiding breaking circular dependency handling is too complex for DDs to handle.
Perhaps the thing to do is to exhaustively document exactly how to use circular dependencies safely with dpkg. Then people can stop being afraid of them.