Re: lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

[Guillem Jover]

Hi!

On Thu, 2024-03-21 at 23:13:31 +0100, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-03-21):
> > I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
> > is the only udeb with t64 (at least according to the output of
> > `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
> > would be sufficient (and might happen at some point anyway).
> > 
> > For the sake of consistency, I think I'm tempted to suggest a revert of
> > the udeb part (it wasn't renamed so there's a contents vs. package name
> > mismatch anyway).
> 
> Checking libaio's changelog (last mail got sent a little too fast,
> sorry) is enlightening: this library required special attention and
> wasn't just about getting rebuilt with a different package name.
> 
>   
> https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/
> 
> Guillem is absolutely right regarding avoiding the roundtrip to NEW and
> d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
> would have been welcome.

Ah, sorry, the heads-up part didn't cross my mind, as I guess I
assumed transitory breakage was expected as part of that transition,
and that it would auto-heal after the release-team would trigger the
necessary binNMUs. Will try to have that in mind in the future. (I'll
do so as well once/if I revert the libaio SONAME bump, even though there
I'd be planning to add backwards compatibility symlinks if the ABI does
not change from what upstream accepts.)

Thanks,
Guillem

lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2024-03-21):
> I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
> is the only udeb with t64 (at least according to the output of
> `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
> would be sufficient (and might happen at some point anyway).
> 
> For the sake of consistency, I think I'm tempted to suggest a revert of
> the udeb part (it wasn't renamed so there's a contents vs. package name
> mismatch anyway).

Checking libaio's changelog (last mail got sent a little too fast,
sorry) is enlightening: this library required special attention and
wasn't just about getting rebuilt with a different package name.

  
https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/

Guillem is absolutely right regarding avoiding the roundtrip to NEW and
d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
would have been welcome.

It'd be nice if the Debian LVM Team (hello waldi) could pick it up from
here and see whether requesting a binNMU is what makes most sense here,
or if there other plans on the t64 front. A local, cowbuilder-powered
rebuild of unstable's lvm2 results in udebs referencing libaio.so.1t64
as expected (i.e. libaio1t64's shlibs).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature