>I've looked at how to make a package where upstream installs systemd >service and timer units to not start the service during package postinst. "systemctl mask unit_name --runtime" ? The masked unit in /run will go away on reboot.
>If I have to manually list each and every unit explicitly that will likely >lead to me missing to update it when a new one gets added upstream. If the upstream package really ships a *lot* of timers/services, it could define a *single* target on build and pull everything from there. >> RefuseManualStart=yes > I'm skeptical that's actually gives the desired behaviour. > As you probably figured, I'm not completely sold on your suggestion. Indeed, this is only a good practice that solves the most simple cases. > I don't want to disallow manual startup. > I want the *package* to not manually start the service (ever). That gets complicated, AFAIK systemctl doesn't care by who it is called. Maybe you'd the need to patch the package or duplicate the unit; neither seems nice solutions. > look at the manpage to find the proper commandline arguments, Why not "systemctl cat fstrim.service | grep ExecStart" ? > Do you know any case where a matching service+timer actually wants > both started on package install/upgrade? No, I think your patch make sense, and enable sane defaults that can be overiden if needed; ...but I'm not in pkg-systemd-maintainers and I'm not the right person to apply/review it. The only native timer I've found in Debian packages is systemd-tmpfiles-clean.timer; and a lot left to be decided for native timers "early adopters". At some point, the Policy should state what to do for upstreams that ships both crontabs in /etc/cron.d/ and a matching native timer. ( the crontab remains needed by sysvinit + cron users) Alexandre Detiste -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
