Bug#992711: debhelper: Please provide backport for bullseye

[Michael Biebl]

Am 23.08.21 um 22:29 schrieb Mattia Rizzolo:

We are talking about this 2-line change in update-rc.d:
https://salsa.debian.org/debian/init-system-helpers/-/commit/552e993488a403bf88aa342f73bf0b22ce62ff16 



Sure, we can add that. It's simple enough.
And as I tried to explain, it's a codepath that shouldn't be hit in the 
"normal" case anyway as either systemd is installed or the package in 
question is using a newer compat level.


I think it's feasible to add that in buster in the next point release, 
and with it allow debhelper  to safely move the .service files also 
in bullseye-backports.




In bullseye, everything is installed in /lib/system/system.
It just feels a bit weird that we now start moving files in a "stable" 
release (I consider bullseye-backports as part of stable).

That's not really a technical concern though.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992711: debhelper: Please provide backport for bullseye

[Mattia Rizzolo]

We are talking about this 2-line change in update-rc.d:

https://salsa.debian.org/debian/init-system-helpers/-/commit/552e993488a403bf88aa342f73bf0b22ce62ff16

I think it's feasible to add that in buster in the next point release, and
with it allow debhelper  to safely move the .service files also in
bullseye-backports.

Wouldn't you consider this option?

On Mon, 23 Aug 2021, 9:42 pm Niels Thykier,  wrote:

> Michael Biebl:
> > Hi Niels
> >
> > Am 23.08.21 um 08:19 schrieb Niels Thykier:
> >> [...]
> >
> > systemd in buster (v241) does support reading unit files from
> > /usr/lib/systemd/system (see systemd-analyze unit-paths).
> > The changes to init-system-helpers (namely update-rc.d) to also consider
> > unit files in /usr/lib/systemd/system was added in 1.58, i.e. is
> > currently only available in bullseye.
> >
> > This code path in update-rc.d is only used for older compat levels
> > though. Newer debhelper versions disentangled dh_installinit and
> > dh_installsystemd and we don't use update-rc.d if
> > --skip-systemd-native is used, see commit
> > cba2a8a6ea64773e61ab41c218853ee729656650 in debhelper.
> >
>
> Thanks for the analysis. :)
>
> > Also, the code in update-rc.d is only a fallback when the "real"
> > systemctl is not available to create the enablement symlinks.
> >
> > If we hit this code path and update-rc.d does not find the .service
> > file, it silently skips the enablement of the service. The package
> > should still install successfully.
> >
> > So is it safe? I'd say reasonably so.
> >
>
> My reptile brain reaction to this is that it smells like "fails to
> install correctly and failing to declare to do so" if we do not enable a
> system when we should have.
>
> I get that most installations that do not have systemd are unlikely to
> switch to systemd later but I do want it to "just work(tm)".
>
> > Question is, if we should start moving unit files in
> > bullseye(-backports) where everything is installed in /lib from a
> > consistency PoV.
> >
> > Regards,
> > Michael
> >
>
> That is the crux of this request.  The backport was requested to ensure
> consistency between bullseye and buster builds (see the OP for details;
> I omitted them in my forward to you as I thought they were irrelevant to
> my question).  Personally, it is easier for me if both cases use the
> same path but only if works for -backports as well.  If we are not
> certain it is safe, then I will look at using /lib for -backports even
> if it means I cannot comply with this request.
>
> Thanks,
> ~Niels
>
>

Bug#992711: debhelper: Please provide backport for bullseye

[Niels Thykier]

Michael Biebl:
> Hi Niels
> 
> Am 23.08.21 um 08:19 schrieb Niels Thykier:
>> [...]
> 
> systemd in buster (v241) does support reading unit files from
> /usr/lib/systemd/system (see systemd-analyze unit-paths).
> The changes to init-system-helpers (namely update-rc.d) to also consider
> unit files in /usr/lib/systemd/system was added in 1.58, i.e. is
> currently only available in bullseye.
> 
> This code path in update-rc.d is only used for older compat levels
> though. Newer debhelper versions disentangled dh_installinit and
> dh_installsystemd and we don't use update-rc.d if
> --skip-systemd-native is used, see commit
> cba2a8a6ea64773e61ab41c218853ee729656650 in debhelper.
> 

Thanks for the analysis. :)

> Also, the code in update-rc.d is only a fallback when the "real"
> systemctl is not available to create the enablement symlinks.
> 
> If we hit this code path and update-rc.d does not find the .service
> file, it silently skips the enablement of the service. The package
> should still install successfully.
> 
> So is it safe? I'd say reasonably so.
> 

My reptile brain reaction to this is that it smells like "fails to
install correctly and failing to declare to do so" if we do not enable a
system when we should have.

I get that most installations that do not have systemd are unlikely to
switch to systemd later but I do want it to "just work(tm)".

> Question is, if we should start moving unit files in
> bullseye(-backports) where everything is installed in /lib from a
> consistency PoV.
> 
> Regards,
> Michael
> 

That is the crux of this request.  The backport was requested to ensure
consistency between bullseye and buster builds (see the OP for details;
I omitted them in my forward to you as I thought they were irrelevant to
my question).  Personally, it is easier for me if both cases use the
same path but only if works for -backports as well.  If we are not
certain it is safe, then I will look at using /lib for -backports even
if it means I cannot comply with this request.

Thanks,
~Niels

Bug#992711: debhelper: Please provide backport for bullseye

[Michael Biebl]

Hi Niels

Am 23.08.21 um 08:19 schrieb Niels Thykier:

Hi systemd maintainers,

I have been asked to backport debhelper to bullseye-backports.

Before I do that, I would like to confirm whether this is sake to
backport for people upgrading from oldstable (+backports) to buster
(+backports)[1].
   As I understand it, support for "usr/lib/systemd/system" was added in
buster and the upgrade would have the systemd from oldstable running
(not to mention the helper scripts used in maintscripts - but that might
be solvable with a Pre-Depends).

Can you help understand that situation and what is needed to make it
safe (or confirm that it cannot be done safely).


systemd in buster (v241) does support reading unit files from
/usr/lib/systemd/system (see systemd-analyze unit-paths).
The changes to init-system-helpers (namely update-rc.d) to also consider 
unit files in /usr/lib/systemd/system was added in 1.58, i.e. is 
currently only available in bullseye.


This code path in update-rc.d is only used for older compat levels 
though. Newer debhelper versions disentangled dh_installinit and 
dh_installsystemd and we don't use update-rc.d if
--skip-systemd-native is used, see commit 
cba2a8a6ea64773e61ab41c218853ee729656650 in debhelper.


Also, the code in update-rc.d is only a fallback when the "real" 
systemctl is not available to create the enablement symlinks.


If we hit this code path and update-rc.d does not find the .service 
file, it silently skips the enablement of the service. The package 
should still install successfully.


So is it safe? I'd say reasonably so.

Question is, if we should start moving unit files in 
bullseye(-backports) where everything is installed in /lib from a 
consistency PoV.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992711: debhelper: Please provide backport for bullseye

[Niels Thykier]

Hi systemd maintainers,

I have been asked to backport debhelper to bullseye-backports.

Before I do that, I would like to confirm whether this is sake to
backport for people upgrading from oldstable (+backports) to buster
(+backports)[1].
  As I understand it, support for "usr/lib/systemd/system" was added in
buster and the upgrade would have the systemd from oldstable running
(not to mention the helper scripts used in maintscripts - but that might
be solvable with a Pre-Depends).

Can you help understand that situation and what is needed to make it
safe (or confirm that it cannot be done safely).


Thanks,
~Niels

[1] As in people upgrading directly into buster with backports.  It is
safe if people upgrade to buster first, reboot and then add backports
later as far as I understand the situation.

Bug#992711: debhelper: Please provide backport for bullseye

[Felix Lechner]

Hi,

This change to debhelper's doc-base installation paths [1] also
requires a debhelper backport to bullseye in order to re-calibrate
Lintian's test suite automatically. Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/debian/debhelper/-/commit/8eac421c260e62bcecd571af225438e107b33157

Bug#992711: debhelper: Please provide backport for bullseye

[Felix Lechner]

Package: debhelper
Severity: wishlist
Control: block 992465 by -1

Hi,

Will you please provide a backport of a recent debhelper version to bullseye?

I use Debian stable (now bullseye) when working on Lintian and cannot
test several important changes to existing checks without the new
debhelper version. A notable example is the changing installation path
for systemd service files described here. [1][2][3][4]

The changes affect many tests in the Lintian test suite. Thanks!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/992465
[2] https://bugs.debian.org/987989
[3] 
https://salsa.debian.org/debian/debhelper/-/commit/d70caa69c64b124e3611c967cfab93aef48346d8
[4] https://lists.debian.org/debian-devel/2021/08/msg00275.html