Hi, On Sun, May 16, 2021 at 10:00:29PM +0300, Dmitry Shachnev wrote: > We determined that the reason for users getting libqt5gui5-gles installed > is the qt5-default package. We removed it in October 2020 because it is no > longer needed. But the latest version of that package that ever existed had > this dependency: > > Depends: qtbase5-dev (= 5.14.2+dfsg-5) | qtbase5-gles-dev (>= 5.14.2+dfsg) > > The latest available version of qtbase5-dev cannot satisfy that dependency, > but the latest version of qtbase5-gles-dev can! The self-inflicted joy of avoiding a transitional package (see also the other thread about transitional packages on d-d@ I should comment) and of too strict dependencies (just because its the same source package doesn't mean = is a good choice; >= would have avoided that mess). ☺ > So for people who had qt5-default installed, apt tries to replace the normal > Qt stack with -gles one to keep that dependency satisfied. It does so even > if it's going to remove qt5-default anyway! Yeah, greedy solver at its best. The problem is here mostly that an earlier part of the solver has figured out (since bit more than a year now) that the dependencies of qt5-default can't be satisfied (as it tries to remove itself), but a) this knowledge isn't used much in the caller yet and b) a later part who is usually responsible for contested remove decisions isn't as good at figuring it out yet, so it decides to try the bad gles subtree and as greedys are bad at reconsidering their decisions it leads down to madness. That specific case might actually be solvable on the apt side with some more heavy work I intend to do eventually (just like I did for the mentioned earlier part), but as you might expect, this isn't appropriate to even think about while in freeze so don't hold your breath – and less clear instances of this will probably remain out of reach still, so lets look at our options: > As an attempt to solve this problem, I added "Breaks: qt5-default" to both > qtbase5-gles-dev and libqt5gui5-gles packages yesterday [2]. I thought this > would convince apt to not consider these packages as a way to satisfy > qt5-default dependency. But that did not work :( Add the Breaks also to qtbase5-dev. Also, make that breaks versioned so that you can reintroduce qt5-default if that turns out to be needed (Lintian probably complains about it, too). Usually I would recommend reintroducing qt5-default, but as you described it as a sid-user only problem it seems more beneficial to keep it removed for everyone rather than to readd for sid only confusing users who want to look up if a removal of qt5-default is okay or not. As qtbase5-dev is installed and depended on while nobody likes qt5-default anymore the ProblemResolver will have an easy time figuring out that removing qt5-default is better than holding back qtbase5-dev would be and hence as a second step wont try to save qt5-default by installing qtbase5-gles-dev (just to then figure out that gles-dev breaks qt5-default, so it has to remove the later anyhow). Thanks for looking into this: That seems like a simpler and less controversial example than the one I used for the last big round of resolver changes … and sorry it took me a while to reply. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature