Control: reassign -1 libsvtav1enc1d1 1.7.0+dfsg-2
Control: severity -1 serious
(While I am not a release team member, they tend to consider upgrade
problems a release-critical bug, so bumping accordingly, although they
do so usually much closer to a release… feel free to disagree.¹)
On Wed, Dec 20, 2023 at 12:20:10AM +0100, Vincent Lefevre wrote:
> I'm currently upgrading a stable machine to unstable (except some
> buggy packages), which is mostly done, but apt fails to resolve
> dependencies in order to upgrade vlc (aptitude is worse):
>
> qaa:~> apt install -s vlc
You should really know this by now as that isn't your first report, but
okay: Upgrade problems are NEVER a problem to be solved in apt,
they are ALWAYS a problem in the involved packages. NO EXCEPTIONS.
The reason is simply that we can't change apt/stable even if we wanted
to, so whatever apt/stable does is what maintainers have to make it work
with.
apt is also not a good place to report a bug to, in the hope they will
figure out where it belongs instead: Two active maintainers don't scale
to the task of bug triage for 70.000+ binary packages AT ALL. We hardly
manage to deal with the reports coming in which sorta belong here…
> [...]
> The following packages have unmet dependencies:
> vlc-plugin-base : Depends: libavcodec60 (>= 7:6.0)
> Depends: libavformat60 (>= 7:6.0)
> vlc-plugin-video-output : Depends: libavcodec60 (>= 7:6.0)
> E: Unable to correct problems, you have held broken packages.
>
> Why doesn't it try to install these packages, then?
Because it quickly tried and gave up on it as the debug output shows:
Installing libavcodec60 requires removing libavcodec59, the later is
deemed more important as (more) stuff still mentions it, so that isn't
done.
Or, well, its actually mostly a matter of libsvtav1enc1 vs
libsvtav1enc1d1 as that is what prevents the two libavcodecs to be
co-installable and why I am assigning this report there.
The gist of this for a package maintainer, especially if your package
is a library, is that you should really really really try to have your
different ABI versions co-installable as otherwise it
| is not ideal due to potential issues during upgrades
(^ foreshadowing in #1041302 introducing libsvtav1enc1{,d1})
The potential is gone, its an issue at least for this user. Not just
in this install request, but also in upgrades as can be reproduced with
the status file from the aptitude report #1059071. Simply telling apt
to "apt full-upgrade -o dir::state::status=./status -s libsvtav1enc1-"
makes that upgrade a lot more sensible than without the explicit removal
of libsvtav1enc1 (without it, it actually ends in a resolver error about
emacs-gtk which seems completely unrelated… except its only 4 stops
on the dependency tree away and so not unrelated at all).
Assuming this 1 vs 1d1 remains not co-installable it would help apt (and
aptitude and anyone else reasoning about this stuff) to make the conflict
between libavcodec60 and libavcodec59 more explicit. In local testing a
simple breaks of the later on the former does the trick.
Of course, that is pushing the potential for issues up the stack, so
another solution might be found (like upstream bumping SONAME, so that
different libsvtav packages from stable and future testing are co-
installable (ignoring the inbetween 1d1)) and hence also libavcodecs.
btw: Before someone asks: That this happens for libavcodecs is mostly
due to its rather unique circumstance of having multiple packages have
or-group dependencies on multiple ABI versions. That grants all of them
points which ideally would only go to the most recent one. The result is
that a resolver believes touching this package would affect many packages
negatively, which isn't [completely] true in this specific case, but a
key concept of apts current resolver and a very handy assumption to avoid
being all to eager to remove packages in transitions. To really detect
this without domain knowledge in reasonable code a solver would need to
try and see what happens, which apt can't – and given aptitude doesn't
see it either tells me that this is only "obvious" with domain knowledge.
I am therefore not considering this a bug in apt. At least not one that
can reasonably be resolved.
Long story short: That apt doesn't find the solution you ask for is sad,
but sometimes that is a good thing, too. And if not, its a problem for
the maintainers of the packages not providing a smooth upgrade path.
Oh and it doesn't matter in this case as it effects also upgrades, but
install is not an upgrade tool. Your system should be fully upgraded
before you install additional stuff as install is simple not up to the
task of making complicated upgrades work (by choice & design!).
Best regards
David Kalnischkies
¹ Ironically, its not a policy requirement to have a package be
upgradable. I could perhaps invoke 'critical' due to making
unrelated software break… but how unrelated can apt really be
to a Debian package I wonder… its usually easier to just fix
the problem than letting me reason about its severity. 😉
Attachment:
signature.asc
Description: PGP signature