Bug#963196: after debhelper 11 => 12 upgrade libexec files are installed in a different directory
On Sat, Nov 07, 2020 at 11:04:36AM +0100, Niels Thykier wrote:
> On Sat, 20 Jun 2020 11:30:03 + Jelmer Vernooij
> wrote:
> > Package: lintian-brush
> > Version: 0.70
> > Severity: important
> >
> > As seen in
> > https://salsa.debian.org/cinnamon-team/cinnamon/-/merge_requests/9,
> > upgrades from debhelper 11 to debhelper 12 by lintian-brush will sometimes
> > result in
> > files no longer being installed.
> >
> > The relevant bit from the debhelper changelog appears to be:
> >
> > The build systems meson and autoconf no longer explicitly set the
> > --libexecdir variable and thus relies on the build system default - which
> > should be /usr/libexec (per FHS 3.0,
> > adopted in Debian Policy 4.1.5).
> >
> > If a particular upstream package does not use the correct default, the
> > parameter can often be passed manually via dh_auto_configure(1). E.g. via
> > the following example:
> >
> > override_dh_auto_configure:
> > dh_auto_configure -- --libexecdir=/usr/libexec
> >
> > Note the -- before the --libexecdir parameter.
> >
> > Looking at the logs, it seems like the old build passed in
> > --libexecdir=\${prefix}/lib/x86_64-linux-gnu
> >
> > lintian-brush can automatically set this flag for packages that it upgrades
> > to
> > debhelper 12, but ideally it would only do so for those packages that ship
> > anything in libexec.
> >
> > [...]
> I think a better solution would be if the janitor could fixup
> "\${prefix}/lib/x86_64-linux-gnu" in debian/*.install instead. If would
> often appear as "usr/lib/*/..." or "usr/lib/${...}/...".
>
> The tricky part here is that if it is a library, the original dh_install
> line needs to stay as well for the .so file.
>
> Admittedly, I am speaking from a "nice to have" or "in the perfect
> world" scenario. The proposed solution would work and that is relevant
> in itself.
Yeah, the challenge here is that lintian-brush runs on the package before
it's built, so it would need to figure out which files are going to
move.
We could assume that everything that's not a library would move to
libexecdir. Upstream may not have classified things appropriately
though. Ideal would be if we could ask automake which files would be
installed into the libexecdir and then just move those, but it doesn't
like there is a way to query automake for that information.
Cheers,
Jelmer
--
Jelmer Vernooij
PGP Key: https://www.jelmer.uk/D729A457.asc
signature.asc
Description: PGP signature
Bug#963196: after debhelper 11 => 12 upgrade libexec files are installed in a different directory
On Sat, Nov 07, 2020 at 11:07:54AM +0100, Niels Thykier wrote:
> Niels Thykier:
> > [...]
> >
> > Hi,
> >
> > I think a better solution would be if the janitor could fixup
> > "\${prefix}/lib/x86_64-linux-gnu" in debian/*.install instead. If would
> > often appear as "usr/lib/*/..." or "usr/lib/${...}/...".
> >
> > The tricky part here is that if it is a library, the original dh_install
> > line needs to stay as well for the .so file.
> >
> > Admittedly, I am speaking from a "nice to have" or "in the perfect
> > world" scenario. The proposed solution would work and that is relevant
> > in itself.
>
> Follow up, my proposal has a caveat for "Multi-Arch: same" packages (in
> that it will not work for those). Just mentioning it for completeness.
>
> I think the common argument is that these binaries do not belong in a
> M-A: same package, but it is an uphill battle for the Janitor to figure
> out how to solve that automatically.
Yeah, it's fine for it to give up and get a developer to manually
handle complicated cases. That seems like a reasonable approach in the
situations where the package is "Multi-Arch: same"
jelmer
--
Jelmer Vernooij
PGP Key: https://www.jelmer.uk/D729A457.asc
signature.asc
Description: PGP signature
Bug#963196: after debhelper 11 => 12 upgrade libexec files are installed in a different directory
Niels Thykier:
> [...]
>
> Hi,
>
> I think a better solution would be if the janitor could fixup
> "\${prefix}/lib/x86_64-linux-gnu" in debian/*.install instead. If would
> often appear as "usr/lib/*/..." or "usr/lib/${...}/...".
>
> The tricky part here is that if it is a library, the original dh_install
> line needs to stay as well for the .so file.
>
> Admittedly, I am speaking from a "nice to have" or "in the perfect
> world" scenario. The proposed solution would work and that is relevant
> in itself.
>
> ~Niels
>
Follow up, my proposal has a caveat for "Multi-Arch: same" packages (in
that it will not work for those). Just mentioning it for completeness.
I think the common argument is that these binaries do not belong in a
M-A: same package, but it is an uphill battle for the Janitor to figure
out how to solve that automatically.
~Niels
Bug#963196: after debhelper 11 => 12 upgrade libexec files are installed in a different directory
On Sat, 20 Jun 2020 11:30:03 + Jelmer Vernooij
wrote:
> Package: lintian-brush
> Version: 0.70
> Severity: important
>
> As seen in https://salsa.debian.org/cinnamon-team/cinnamon/-/merge_requests/9,
> upgrades from debhelper 11 to debhelper 12 by lintian-brush will sometimes
> result in
> files no longer being installed.
>
> The relevant bit from the debhelper changelog appears to be:
>
> The build systems meson and autoconf no longer explicitly set the
> --libexecdir variable and thus relies on the build system default - which
> should be /usr/libexec (per FHS 3.0,
> adopted in Debian Policy 4.1.5).
>
> If a particular upstream package does not use the correct default, the
> parameter can often be passed manually via dh_auto_configure(1). E.g. via
> the following example:
>
> override_dh_auto_configure:
> dh_auto_configure -- --libexecdir=/usr/libexec
>
> Note the -- before the --libexecdir parameter.
>
> Looking at the logs, it seems like the old build passed in
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu
>
> lintian-brush can automatically set this flag for packages that it upgrades to
> debhelper 12, but ideally it would only do so for those packages that ship
> anything in libexec.
>
> [...]
Hi,
I think a better solution would be if the janitor could fixup
"\${prefix}/lib/x86_64-linux-gnu" in debian/*.install instead. If would
often appear as "usr/lib/*/..." or "usr/lib/${...}/...".
The tricky part here is that if it is a library, the original dh_install
line needs to stay as well for the .so file.
Admittedly, I am speaking from a "nice to have" or "in the perfect
world" scenario. The proposed solution would work and that is relevant
in itself.
~Niels
Bug#963196: after debhelper 11 => 12 upgrade libexec files are installed in a different directory
Package: lintian-brush
Version: 0.70
Severity: important
As seen in https://salsa.debian.org/cinnamon-team/cinnamon/-/merge_requests/9,
upgrades from debhelper 11 to debhelper 12 by lintian-brush will sometimes
result in
files no longer being installed.
The relevant bit from the debhelper changelog appears to be:
The build systems meson and autoconf no longer explicitly set the --libexecdir
variable and thus relies on the build system default - which should be
/usr/libexec (per FHS 3.0,
adopted in Debian Policy 4.1.5).
If a particular upstream package does not use the correct default, the
parameter can often be passed manually via dh_auto_configure(1). E.g. via the
following example:
override_dh_auto_configure:
dh_auto_configure -- --libexecdir=/usr/libexec
Note the -- before the --libexecdir parameter.
Looking at the logs, it seems like the old build passed in
--libexecdir=\${prefix}/lib/x86_64-linux-gnu
lintian-brush can automatically set this flag for packages that it upgrades to
debhelper 12, but ideally it would only do so for those packages that ship
anything in libexec.
-- System Information: Debian Release: bullseye/sid APT prefers unstable APT
policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lintian-brush depends on:
ii devscripts 2.20.3
ii python3 3.8.2-3
ii python3-breezy 3.1.0-3
ii python3-debian 0.1.37
ii python3-distro-info 0.23
ii python3-dulwich 0.20.2-1
ii python3-iniparse 0.4-3
iu python3-ruamel.yaml 0.16.10-2
Versions of packages lintian-brush recommends:
ii dos2unix 7.4.0-2
ii gpg 2.2.20-1
ii libdebhelper-perl13.1
ii lintian 2.80.0
ii python3-asyncpg 0.20.1-1+b1
ii python3-levenshtein 0.12.0-5+b1
ii python3-pyinotify0.9.6-1.3
ii python3-toml 0.10.1-1
Versions of packages lintian-brush suggests:
pn gnome-pkg-tools
ii postgresql-common 215
-- no debconf information
