Processed: Re: Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Processing control commands: > severity -1 normal Bug #1034234 [libpam-modules-bin] libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system Severity set to 'normal' from 'serious' -- 1034234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034234 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
control: severity -1 normal > "Cyril" == Cyril Brulebois writes: Cyril> serious & wontfix make for a strange combination… Yeah, my bad for dropping the ball. My intent with wontfix was to create a pause and better understand the issue. As I understand it, * On first install, pam_namespace will require an explicit daemon-reload before it can be started. However pam_namespace requires explicit administrator configuration * We don't want pam_namespace to be started automatically, so it's great that it isn't today * it's possible that on upgrade or remove it might not be stopped. That's not a bug today but will be next time the code for the namespace helper service changes. None of that sounds RC to me. Not even important, although I can see an argument either way there and would be happy to stand aside (or even do the work) if Steve thinks we should fix this. I'm very uncomfortable moving files between / and /usr especially in an essential package. Between the issues Simon has documented over the years with libraries and the dpkg aliasing bugs, we've managed to hurt ourselves with this a number of times. I *think* this situation is safe. But when I read the freeze policy, none of the issues mentioned above justify a change this late in the release process. I definitely do not think we could undo the change if we make it until dpkg fixes the aliasing bug. The suggestion in Lauren't initial bug report that it would be appropriate to undo this change after the bookworm release really frustrated me. It displayed a complete lack of understanding of the dpkg aliasing issues, and I didn't manage to overcome that frustration enough to look at this issue again until your mail prompted me. Thanks for that. If I've mischaracterized the severity of the potential harm above, let me know. I don't want a broken pam, but I also consider this kind of move moderate risk. --Sam
Processed: Re: Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Processing control commands: > tag -1 patch Bug #1034234 [libpam-modules-bin] libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system Added tag(s) patch. -- 1034234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034234 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: tag -1 patch
Sam Hartman (2023-04-11):
> control: tags -1 wontfix
serious & wontfix make for a strange combination…
> > "bigon" == bigon writes:
>
> bigon> It seems that your package libpam-modules-bin is shipping
> bigon> files (.service, .socket or .timer) in
> bigon> /usr/lib/systemd/system.
>
> I think we're talking about pam_namespace.service.
> I don't think dh_installsystemd has anything to do for that file because
> it has no Install section.
> What harm is caused by pam_namespace.service being in /usr/lib/systemd?
To expand on Lauren't answer, you're currently lacking these:
- postinst:
#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action 'pam_namespace.service'
>/dev/null || true
fi
fi
# End automatically added section
- postrm:
#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.11.4
if [ "$1" = remove ] && [ -d /run/systemd/system ] ; then
systemctl --system daemon-reload >/dev/null || true
fi
# End automatically added section
- prerm:
#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.11.4
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system
] ; then
deb-systemd-invoke stop 'pam_namespace.service' >/dev/null || true
fi
# End automatically added section
FWIW it's just a matter of changing the last line of
debian/libpam-modules-bin.install to:
usr/lib/systemd/system/pam_namespace.service /lib/systemd/system/
Patch attached.
Cheers,
--
Cyril Brulebois (k...@debian.org)
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Le 11/04/23 à 19:53, Sam Hartman a écrit : control: tags -1 wontfix "bigon" == bigon writes: bigon> It seems that your package libpam-modules-bin is shipping bigon> files (.service, .socket or .timer) in bigon> /usr/lib/systemd/system. I think we're talking about pam_namespace.service. I don't think dh_installsystemd has anything to do for that file because it has no Install section. What harm is caused by pam_namespace.service being in /usr/lib/systemd? dh_installsystemd also takes care of calling systemctl daemon-reload when a new .service file is installed/removed, it also takes care that the service is stopped before removing the package (in this case it's a short living/oneshot service, but still) bigon> debhelper? As soon as debhelper is supporting (not until bigon> bookworm+1 aka Trixie) you will be able to move them back to bigon> the newer location. Um, no doing that before dpkg is fixed to deal with aliasing could potentially be a really bad idea. I'm not sure I understand, if all the files are at package level moved to /usr instead of / then aliasing in dpkg is not needed, isn't it? Again, what harm is caused by pam_namespace.service being in /usr/lib/systemd/system? How is this a bug?
Processed: Re: Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Processing control commands: > tags -1 wontfix Bug #1034234 [libpam-modules-bin] libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system Ignoring request to alter tags of bug #1034234 to the same tags previously set -- 1034234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034234 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Processing control commands: > tags -1 wontfix Bug #1034234 [libpam-modules-bin] libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system Added tag(s) wontfix. -- 1034234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034234 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
control: tags -1 wontfix > "bigon" == bigon writes: bigon> It seems that your package libpam-modules-bin is shipping bigon> files (.service, .socket or .timer) in bigon> /usr/lib/systemd/system. I think we're talking about pam_namespace.service. I don't think dh_installsystemd has anything to do for that file because it has no Install section. What harm is caused by pam_namespace.service being in /usr/lib/systemd? bigon> debhelper? As soon as debhelper is supporting (not until bigon> bookworm+1 aka Trixie) you will be able to move them back to bigon> the newer location. Um, no doing that before dpkg is fixed to deal with aliasing could potentially be a really bad idea. Again, what harm is caused by pam_namespace.service being in /usr/lib/systemd/system? How is this a bug?
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: libpam-modules-bin > Version: 1.5.2-6 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package libpam-modules-bin is shipping files (.service, > .socket or > .timer) in /usr/lib/systemd/system. [...] wrong variable name (systemdsystemunitdir): https://sources.debian.org/src/pam/1.5.2-6/configure.ac/?hl=646#L646 overridden by wrong path: https://sources.debian.org/src/pam/1.5.2-6/debian/rules/#L33 Regards, Andreas Henriksson
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Package: libpam-modules-bin Version: 1.5.2-6 Severity: serious Tags: sid bookworm User: debhel...@packages.debian.org Usertags: systemd-files-in-usr-bookworm Dear Maintainer, It seems that your package libpam-modules-bin is shipping files (.service, .socket or .timer) in /usr/lib/systemd/system. This is not supported by the version of dh_installsystemd/debhelper currently in unstable and bookworm (See: #1031695). That means that currently your service might not be enabled at boot and/or started as expected. With the freeze currently in effect, debhelper will not be fixed for bookworm. As a result, could you please move these files to /lib/systemd/system instead so they are properly detected by debhelper? As soon as debhelper is supporting (not until bookworm+1 aka Trixie) you will be able to move them back to the newer location. Note that bookworm is currently in hard freeze, please limit the changes you are uploading to the ones fixing RC bugs. Also note that you might have to request a freeze exception to the release team. See: https://release.debian.org/testing/freeze_policy.html Feel free to contact me if you have any questions. Kind regards, Laurent Bigonville The list of packages has been generated with the following command: apt-file search -x '^/usr/lib/systemd/system/.*\.(service|timer|socket)$'|cut -d: -f1|sort -u
