Niels Thykier <niels@thykier.net> (2019-07-20): > Thanks for the feedback. :) > > I have tested this and they do. > > Test method: I have verified this against systemd at git master[1] using > the following three variants/builds: > > * Vanilla debhelper/12.2.3 with explicit --add-udeb > * Patched debhelper/12.2.3 with explicit --add-udeb > * Patched debhelper/12.2.3 dropping the "dh_makeshlibs -plibudev1 \ > --add-udeb=libudev1-udeb [...]" line[2] > > All three generate identical results (i.e. bit-for-bit identical > debs/udebs)[3]. Thanks, but that's just a single package. > I will never be able to make code that works all the time given the > premise that people "blindly" apply changes. However, it is not my > goal either. The goal for this change is to simplify udeb handling to > remove one papercut /in the common case/ for udeb packages in two > forms: > > 1) Packages that need to add a new udeb will have one less step to > worry about when they follow the naming convention for udebs. > > 2) /Some/ existing udeb producing packages will be able to drop their > manual overrides (assuming they follow this convention as well). > An example of a package that would benefit is bind9, where we can > remove about 11 lines[4]. > > While most packages seem follow the convention, there are exceptions. > As an example, I spotted fontconfig[5] which will not benefit from this > change. Instead, it (and other exceptions) will have to keep --add-udeb. While I'm of course fine with the idea of automating what can be automated, I think I'd be happier to also see some hint somewhere for maintainers who wish to drop the --add-udeb, e.g. checking the resulting SHLIBS before/after the change… The current situation has been fine since I've been dealing with the installer, filing the occasional bug when a udeb needs to be added (which would still be needed with your patch applied as adding the udeb binary would still be needed); and I wouldn't want to have to deal with “careless” regressions. IOW: Fine with making maintainers' life easier, but please help them double check they don't regress (and end up making mine less so). Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature