On Wed, Jan 27, 2021 at 04:53:50PM +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Jonas Smedegaard (2021-01-27 16:15:17) > > I suspect that's not really the case - that instead apt tools might pick at > > random. > > no, apt does not pick at random. The apt solver prefers the first alternative. To refine this: apt¹ picks the first alternative which is either: 1. already installed and satisfying as is 2. already installed, but needs an upgrade to satisfy 3. not installed, but can (may) be and would satisfy (in reality you have to factor in explicit provides and implicit ones (like M-A:foreign) for all of them individual as well – and while apt has a partial order for those, you don't want to hear the details… just pretend its "clever" "random" between different providers of a given alternative). (And for completeness "A|B, B|C" will have you end up with A and B installed except if e.g. A depends on C, then it will be A and C. So it's depth first for now. If you like this behaviour is a question of how preferable A is over B and how co-installable they are) None of this is explicit requirement by Debian policy (which is silent on many other things apt is required to do by tradition as well), it only sort of follows out of "§7.1 Syntax" saying that any will do while "§7.5 Virtual Packages" says that the default should be the first. Note that if apt¹ can figure out that an alternative will not work it will pick another alternative which may or may not be what you meant with "is not available" as that (especially in unstable) includes if a dependency of this alternative is not satisfied. Sounds innocent and simple, right? Consider that this includes all types of dependencies, not only the positive depends on a not-yet build other package but also e.g. conflicts with another package which must be part of the solution (= a direct chain without other solutions from initial to this package exists) or breaks you thought are there to force an upgrade of a package, but as that version isn't built yet effectively means that the package has to be removed instead. So, without giving this a deep inspection my guess is simply that in these cases apt managed to figure out that libqt5gui5 was not a good alternative at the moment the user made the install/upgrade and went on and choose the other. That's the point of alternatives after all. In a way, that might be a regression of me working on those conundrums last year to have apt figure out these things better to avoid breaking recommends (in which these or-group and provides problems exist as well) and letting apt find solutions which would previously be errors (as it picked an unworkable alternative at first and wouldn't be able to recover from it later on). So some (not all, apt always tried hard, it just a bit more clever about it) of these users might previously be greeted by apt error messages until the unstable archive stabilised reporting bugs against apt as a solution "clearly" exists while apt will now find that solution you would prefer it not to find it seems. > I really would like to prevent this from happening for other users, > so any suggestions would be welcome. I don't think there is a solution to your problem – assuming that is indeed this problem as I am only guessing – as at the very end its a problem of the user accepting a solution they shouldn't, but to know that you need to have specific domain knowledge. The hidden joys of Debian unstable I guess… (doesn't help that it sort of sounds like a package rename when libqt5gui5 is removed and -gles installed). That said, I find it a bit odd that only libqt5gui5-gles conflicts with libqt5gui5. I doubt it will help apt, but it seems more honest to also have the reverse. Fun fact: having it only on one side actually gives the one having it a scoring advantage in apts conflict resolution, so for apt it reads in fact like -gles is the preferred package of the two making it less likely that apt holds back libqt5gui5. In practice other score points should level the playing field for libqt5gui5 though. (At least on my system more things depend on it than -gles provides). Best regards David Kalnischkies ¹ Then I say apt here I mean the default resolver parts implemented in libapt and used wholesale by pretty much everything using that library including apt, apt-get, synaptics, various software centers, … aptitude being a notable exception with its own resolver reusing only some parts and reimplementing others which may or may not include the parts responsible here (it is not an exaggeration when I say we have no active Debian contributor who could answer that question as the only person knowing how the aptitude resolver works went MIA years ago. So the main reason it still (FSVO) works is that supercow is benevolent). The other notable exception would be (c)debootstrap, but you have other problems to worry about if your package is part of the early bootstrap before those manage to install apt and delegate the rest to it. May supercow have mercy with your soul if you are still a dselect user (which also uses apt, but for other things). There is cupt as general propose package manager intended to be an apt competitor, but I mention that only to be able to claim that apt is no monopoly in the Debian ecosystem as any respectable monopoly is legally required to deny its own existence. I said "default" for a reason though: libapt can be told to use an external resolver and buildds e.g. do for experimental in the form of aspcud. All bets are off in their choices, but it tends to be the intended behaviour that they ignore constrains apt follows like which alternative to use (as the constrain is e.g. on less changes instead). Non special-interest users can likely be counted on one hand though. If you think there is an apt bug somewhere, we will need an actionable report, which in this case would be an EDSP file you can produce with the special external resolver 'dump' (append --solver dump and set the envvar mentioned by it for a second run) from a run producing the "wrong" solution. You could also ask users to pick dpkg/status files from backups and combine with snapshots.d.o to travel back in time.
Attachment:
signature.asc
Description: PGP signature