Control: reopen -1 Control: tags -1 - pending Control: severity -1 wishlist Control: retitle -1 deal with mutually-exclusive essential package sets # wrong bug number in commit message… On Fri, Nov 27, 2015 at 11:43:43AM +0100, Thorsten Glaser wrote: > I just got upgraded… > | Unpacking apt (1.1) over (1.0.10.2) ... > … and now, a dist-upgrade has a regression. That isn't a regression but just happened to happen now. It could be any version as its just depending on: > Investigating (0) dash-mksh [ amd64 ] < 6 > ( shells ) > Broken dash-mksh:amd64 Conflicts on dash [ amd64 ] < none -> 0.5.7-4+b1 > ( shells ) > Considering dash:amd64 5207 as a solution to dash-mksh:amd64 5203 > Removing dash-mksh:amd64 rather than change dash:amd64 > Done 4 points, that isn't much. If I write a testcase with just dash and dash-mksh it e.g. still "works", I have to add another package which depends (multiple times) on dash to make it have the bad outcome. I am not sure how that could be fixed or if we even want to. Essentials have to be installed, so you just can't have mutually- exclusive essentials in any supportable capacity. In that situation we have a provides, but that isn't to expressive: Who knows if (= 2147483647:1) is actually high enough given that nothing has to depend on essentials. Even without a version, we have this golden rule of prefering real over virtual packages all things considered equal… Even if we manage to make it believe dash-mksh is essential enough to take over the essentialness of dash, what about upgrades then if dash-mksh is removed some day (from your achive, or the user removes the archive, or or or). So given that I have no idea how to approach a fix, I assume its very complicated for a very small gain as essentials are usually not exclusive by design and the "workaround" is easy enough: pinning. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature