Hello,
Holger Wansing <
hwansing@mailbox.org> (2024-12-19):
I just noticed that many d-i packages currently get a lintian error "aliased-location", complaining about binaries in locations, which are
now under the concept of usrmerge (aka /bin, /sbin and /lib).
Since udebs are sometimes a little bit different from "normal" Debian packages, I would like to ask, if this is an issue for these packages
or not.
Important topics:
- does the package build?
- does it get accepted when it reaches the archive?
- is the runtime within d-i OK?
If you get a triple yes, the rest doesn't matter.
Should we change this, or is the lintian error a false-positive?
At this point, I don't know, and I don't want to know. This move has
been a HUGE mess for MANY years. And if we don't run into troubles as it
is, then I don't see a need to change anything.
If that doesn't lead to an autoreject, it's perfectly fine to ignore
those errors, and not to add any overrides. It's best to think about
the topic first, then decide whether we need/want to do something on the
udeb side, get lintian to skip those checks on udebs, and/or use
overrides.
(My gut feeling would be we should have udebs close to their counterpart
debs, but should it happen right now? Absolutely not. :))
And do we want to change it *now*?
Even if we needed, or wanted, to do anything about that, it would make
sense to get everything at the same time, not one package here and one
other package there.
Ideally that kind of change should get discussed on the list first, and
if there's an agreement about needing/wanting to implement the changes
vs. the associated risks, then we can talk about a timetable and
proceed. So thank you very much for starting this thread, that's
perfect.
Pascal 'pham' already mentioned, that d-i under trixie has merged-usr
in initrd.gz, but I want to make sure, before pushing changes to
several d-i packages, thus this mail...
See for example https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/23 https://salsa.debian.org/installer-team/anna/-/merge_requests/5
Testing of images with such changes did not show any issues.
That's a useful datapoint, thanks for that as well.
Over the past few weeks I've spotted a number of issues that'd be
blockers for a release, and most if not all of them have been fixed in
the last few days.
If you want to include more l10n changes at this point that's still
fine, but delaying other code changes would have my preference at this
point. I'll have to check a few more things before mailing the usual
reminder to dda@ about freezing udeb-producing packages temporarily,
check with the images team, and wade through the website and other
places to prepare for Trixie Alpha 1.
(There's some bit of uncertainty regarding the unshare thing on the
buildd side — I'm not sure I looked into the proper puppet bits — but
we'll see what happens when src:debian-installer gets uploaded next
time.)
Cheers,
--
Cyril Brulebois (
kibi@debian.org) <
https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmdkxxQACgkQ/5FK8MKz VSAsdg//bJk2QQsLW5VLwpEeGtcp+KI/Lga/+sGEZ/9A7YnDDj6rJkj8gKDpfc3A Vep8mAW8eSfj/12UaVQAqce2LwsCBXmELhxmvw60c082zr34LUVsDkO5kCVHRAmq AijpWLUNUDObASjsZZofg7Y5qPg2BSm1e2b3YHQflQy2Ia/hr5oVCntRyn4lsMaP KjwgDuQbBjFbVWnEEJ6s9S2xnA0OzN9Iu9k5VqdtmeoEMBWYsYohQfbbgSnK8iOZ OsODwtcn+G+W6as+ogp+qOMHZN7Dj2ezGk18n6zF6+mVpIBvC7VCrvXXSeyBedGF 6852YuYNB/KnoSyDDWp0eWzTepl0eM2kHzh+Ecvx5KHAqDH++JE3w9VmSmLHFeGx 1EsrOru3W7L8ez9KJ+HA0QMfsEGD4yGml3zNgMOjFm2MeA6LFcI9QCXv9KaTj7Ov watc1n4OgPUIOBV4us4WhpB5FtDYaespcid8vrfpFc0Mke/vwK78dKki9YQQXb1R 9VpNARUzeTkC7vka5vdeBHJn6Gs5uc0ftLKGAs6jYcyx8QGwzI4UiLsB0zHyE9mo vqGaSGtzdaUW12KveUnT2nl3wt1c93eM+/D+FniRaTYD4/Jwh7XdvsrxIwZLULVv DS2BbMhYWwlPCqp0o08D1M6YXIv+j0H8h+G3mHC5QZFuFN7QMLw=
=O97D
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
*