Your message dated Wed, 6 Mar 2024 20:28:53 +0100
with message-id <[email protected]>
and subject line libuuid1t64: file overlap with libuuid1 causes dependency
conflicts
has caused the Debian Bug report #1065394,
regarding libuuid1t64: file overlap with libuuid1 causes dependency conflicts
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1065394: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065394
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libuuid1t64
Version: 2.39.3-6.1
I am currently unable to generate riscv64 images via debootstrap:
-------
I: Extracting libuuid1...
I: Extracting libuuid1t64...
E: Tried to extract package, but file already exists. Exit...
-------
Both packages obviously provide the same files. "apt upgrade" on an
existing riscv64 system does not have the issue, likely since libuuid1
"Provides" libuuid1t64, and APT resolves this. debootstrap however seems
to not resolve this.
Checking which actual package pulls them:
https://packages.debian.org/sid/e2fsprogs
e2fsprogs depends, for most architectures, explicitly on both: libuuid1
and libuuid1t64. While libuuid1 alone could satisfy both dependencies,
of course this double-dependency of naturally conflicting packages does
not make sense and is an issue in e2fsprogs. But on the other hand,
maybe there is some information missing/misunderstanding about how to
deal with this *t64 packages, which have been introduced all over the
place in Debian Sid/unstable.
So I am not sure where to fix this best, but since it is all around the
introduction of libuuid1t64, I report it here.
Adding either "Breaks"/"Conflicts" between the 2 packages would makes
things pretty clear for everyone else, to only either add dependency for
one or the other, but not both. But not sure whether this works well
with "Provides". A "Provides" in the other direction, that libuuid1t64
provides "libuuid1" might help as well. Or "Replaces" for libuuid1t64 on
libuuid1 so that those can be installed concurrently, but I think this
does not make sense as they really provide only different variants of
the same library.
Let me know whether I should better re-assign the issue to e2fsprogs
and/or debootstrap.
Best regards,
Micha
--- End Message ---
--- Begin Message ---
Package: e2fsprogs
Version: 1.47.0-2.3+b1
The issue (double-dependency) has been solved with the latest build
1.47.0-2.3+b1. It remains only for i386, ppc64 and x32 architectures, as
the rebuild has not been done/uploaded for those, yet.
However, so Chris was right that a rebuild solves it.
Now debootstrap fails on libssl3 + libssl3t64 for the same reason: The
openssl binary package depends on libssl3t64 explicitly, everything else
depends on libssl3 explicitly. libssl3t64 provides, breaks and replaces
libssl3, but debootstrap still tries to install both. Looks like we need
to wait for some more days or weeks until the transition and all related
rebuilds have been done, before we can use again debootstrap.
--
Best regards,
Micha
--- End Message ---
