Control: severity -1 minor On Fri, May 27, 2016 at 11:17:20AM +0900, Sean Whitton wrote: > `apt-get install -f` fails to install dependencies for several packages > that are built using the dh_elpa debhelper addon. […] > Expected result: elpa-company's dependencies are installed and the > package is ready to use. The expected result of a --fix-broken command is that your system is in a consistent state again. That just happens to be most of the time achieved with installing some additional dependencies.¹ It is equally well possible to remove packages to achieve this through. Throwing your arms up and declaring "sorry, can't fix that" isn't the best option, but certainly better than trying to make it work and ending in an explosion. Given the complexity of the solutions (if I see that right apt has to touch nearly a hundred packages here) I would actually recommend to apt to remove the offending package as that is a much shorter (and hence better) way to sanity as "broken" could very well mean "unbootable" so leaving that state fast is very desirable. If only --fix-broken would cater to all the usecases it is misused for (most of the time while people think its --force)… [and -y would only be used if the user is really sure about what will happen…] ¹ that this is the first choice makes the "old way of installing *.deb files" kinda working as an accident. --fix-broken was initially created to deal with systems were the user installed apt the first time – which usually doesn't happen anymore as apt is nowadays part of the default installation… (thanks to the manpage for this history lesson!). > Workaround: apt-get install ./elpa-company_*.deb successfully installs > the dependencies. That is NOT a workaround! That is how you are supposed to install *.deb files as --fix-broken is the partly working workaround from the times in which apt didn't have a good way of installing debs and people figured out that --fix-broken will do what they want in maybe 90% of the cases… > The failure is either uninstalling the elpa-* package, or a failure to > find any resolution; it varies depending on the elpa-* package I test. > I attach two example terminal transcripts made with script(1).[1] So, as said, uninstalling is okay. Not finding any solution isn't nice through, so that is what I consider a bug here, but somewhere between minor and wishlist, not "important", as nothing explodes here, apt just gives up while trying to fix the mess you placed it in (without a good reason I have to add). > Since emacs depends on libgnutls, it is possible that this bug is a > duplicate of #815650; I'm filing a separate bug since that's just > a hunch. Red hering; completely unrelated as yours is a problem in the resolver while this one is with the interaction between APT↔dpkg which in the resolver failing cases isn't even part of the execution path. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature