On Thu, Jul 23, 2015 at 06:59:19PM +0200, Raphael Hertzog wrote: > Regression introduced in 50ef3344c3afaaf9943142906b2f976a0337d264. Nitpicking, but that commit "just" breaks this completely, it was broken before if a package changed sections (like oldlibs usually do) … In general, I would be happy if you could formalize the manual tests you have done in a testcase for ./test/integration as that is the kind of stuff which is never tested manually if you don't happen to suspect something to be wrong with it in the first place… I mean, the commit you reference… what could possibly go wrong… q.e.d. > Up to now, only dependencies leading to new package installations were > marked as manually installed. With this change, a package that is already > installed and marked as auto-installed and that is needed to satisfy a > dependency of a package maching APT::Never-MarkAuto-Sections will be > switched to manually installed too. The first patch has similar effects for upgrades, but with the second it is indeed as you describe… just… what that means is that a user can't set a package to 'auto' if it happens to be a dependency of a never-markauto package – or, the user can, but his configuration is overridden on the next upgrade/install of a depending never-markauto package as you explicitely set the bit all the time rather than on first install as before (as advertised in your commit message). That could be interpreted as ignoring user configuration… at random. Restoring the old behavior okay, but adding this on top of it… feels wrong even if I understand why you implemented it. Frankly, I never liked this "hack". What we are trying to do here is avoiding theoretical correct autoremove-suggestions on the remove of certain packages as they are in practice cause for confusion at best and a big problem for users who follow the suggestion at the worst. Long story short: I think this hack should finally be replaced with the transition of the manual-bit on "removal" of packages. oldlibs packages should forward their manual-bit to dependencies on remove (and the autoremover calculate with this) just like metapackages should push their bit downwards on removal: mydesktop depends mydesktop-core depends browser, texteditor. On removal of browser, mydesktop-core and mydesktop are removed as well, but the bit of mydesktop is pushed to mydesktop-core and that state is pushed further to texteditor. Bonus points if no pushing happens if I remove mydesktop explicitely. That also means that if mydesktop-core decides that texteditor2 is a better texteditor and flips to it the old obsolete texteditor (as well as the trillion oldlibs it depends on) can leave my system via autoemove (if I am willing to let that happen of course). I implemented a simple autobit forwarding for disappearing packages and at least since then this never-markauto thing is on my list. Having it broken entirely now might be a good excuse to finally work on it… /me adds it to DebCamp list Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature