Hi Andreas, Andreas Beckmann <a...@debian.org> writes: >> We currently do have a few remaining packages which ship files in >> /etc/systemd. Those should be fixed. > > Is there a lintian check for this? Not yet, I think.
>> We could ship /etc/systemd/system in i-s-h, but would that help? > > That would solve the piuparts issue. > i-s-h should ship all directories below /etc/systemd that it might need > to use at some point *and* that are also shipped in the systemd package > (or any "buggy" package) to make it clear: "this directory is managed by > dpkg" (while everything is /var/lib/systemd is solely managed by i-s-h). i-s-h cannot know what some package might want to use at some point underneath /etc/systemd. deb-systemd-helper (which is the part of i-s-h we talk about here) is just a script to create the symlinks necessary to enable a systemd unit file. systemd units live in e.g. /lib/systemd/system/apache2.service. Depending on which target(s) the unit file belongs to, it will be activated by creating e.g. /etc/systemd/system/multi-user.target.wants/apache2.service. Now you could argue that we should just hard-code the most common targets (they are analogous to runlevels in sysvinit), but that doesn’t help: units can also be installed for other unit files. We have that situation in bind9, where bind9-resolvconf.service is a service that, when enabled, is linked from /etc/systemd/system/bind9.service.wants/bind9-resolvconf.service so that it will be started whenever bind9 is started. I hope I made it clear why the hierarchy underneath /etc/systemd/ is too dynamic to be shipped in any single package. What options do we have to fix this piuparts problem? Thanks. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
