Re: Bug#1132024: Add insserv-bin binary package with /usr/libexec/insserv for easily creating Hurd chroots
Johannes Schauer Marin Rodrigues <[email protected]> Mon, 13 Apr 2026 08:55:32 +0200
| Newsgroups | gmane.linux.debian.ports.hurd |
|---|---|
| Message-ID | <177606333285.153604.5954123353820042367@localhost> |
Hi Mark, On Sat, 28 Mar 2026 07:31:07 +0100 Johannes Schauer Marin Rodrigues <[email protected]> wrote: > Quoting Mark Hindley (2026-03-27 20:49:05) > > The conflicts was added to avoid interactions between systemd, initscripts > > and insserv, however support for LSB initscripts in systemd has now been > > removed and I find it unlikely that #1072562 or similar would still be issue > > even if initscripts and insserv were installed on a systemd system. If I am > > wrong in my analysis here, I would be happy to be pointed to a reproducer for > > such an issue. > > I asked Michael Biebl in #debian-devel again about this and the remaining > problem seems to be that most packages still ship sysv init scripts alongside > the systemd service files and that means that maintainer script code is > generated which calls update-rc.d/innserv if present. > > I suggested to change the debhelper snippet which generates the relevant bit in > maintainer scripts but Michael Biebl wasn't happy with that approach either. > > Jochen Sprickerhof brought up that update-rc.d/insserv could behave differently > if DPKG_ROOT is set, but Michael Biebl replied that he has "no interest in > touching this code and investigating all the corner cases". without the systemd maintainers willing to change things I fear that nothing will move. I'd argue that it would be a great boon for ports which cannot have systemd if it were easier to create chroots or bootable images for them from the more common installations which are using systemd. And right now I see no other way forward than adding another binary package which ships insserv at a location that is not in $PATH. Maybe you have another idea? Thanks! cheers, josch
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmnck2QACgkQ8sulx4+9 g+GlnBAAhxABytGpxVqC5K8z0f+PqFkQi/HvbbOdw1bTGaRQ8gRaZu0N5L4viiLQ OZM+90qj5o5zNiQVMkOd/DMP3LBaM326MkmbOYZ/NxEFOdnrX3VLUuUZT+KXN4QQ VT6MMb94c8T4e4trOllKgClZaT+QojprCI9iKwDXQ5Uyu2fh8yh7N32uOoophqja cx0nncNNIZHyFYTMzHIqK+3XxyPirIRp01ENOMLlzkIx2SBPkhFVT3LGjRdNffQ/ n4QuwhZ4Y/Spvlkld0ZSlWJmySp4MkiBI/4XJfu2EjxblHHV+XSuh4nqPMnU9wmP rt+9NapZQzeK0Y304Kzz4Pcx2Y8OO/+YXIGWzeK6LaHoNGaMlsiT6rR41RYltdbH iDM/k1eCIxb/CyYew9ofqP7Js+wmNk6LsSdAr+f1swc+OgT4pvw/sC8gpIWrBmqN PciTbBvvO/7PscYMdBcEACdNVp8l7SMFmoDjdMhqa/ddUBYy85HzpPos2GKHck4w ISpt+Lt2kO6rx+ljWHdcxCy9eCjfmMqTlQKcuLYXYzNOmfl7a5FkKujVcIANHja0 /zDe/oZ29DEIyTL0JdZCPxSg92e9RzAiLRCMtUJFpi/u7sHSX6aaEiUGnA1/oww7 skExho2MTNV+rQhOZgK+8yCu6DyWZPR75nQBK7P3ckeu49X2XFg= =rYLR -----END PGP SIGNATURE-----