[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help required to determine why some packages are being installed

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

Reply to: