Your message dated Sun, 3 Mar 2024 23:40:39 +0100
with message-id <ZeT8Z_ko190L9AYg@per>
and subject line Re: Bug#1065394: 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 ---
On Sun, Mar 03, 2024 at 08:34:18PM +0100, MichaIng wrote:
> 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.
No, it doesn't. It would also be silly, because you cannot coinstall
them.
> Let me know whether I should better re-assign the issue to e2fsprogs and/or
> debootstrap.
Nowhere. Packages need to be rebuilt to get the correct dependency
(libuuid1) again. I'm sure the porters are on it.
Chris
--- End Message ---
