[systemd-devel] How to handle staged installs with a Systemd unit?

[Jeffrey Walton]

On Thu, Dec 26, 2019 at 3:01 PM Mantas Mikulėnas <grawity at gmail.com> wrote:
>
> On Thu, Dec 26, 2019 at 9:29 PM Jeffrey Walton <noloader at gmail.com> wrote:
>>
>> On Thu, Dec 26, 2019 at 9:35 AM Mantas Mikulėnas <grawity at gmail.com> wrote:
>> >
>> > On Thu, Dec 26, 2019 at 2:46 PM Jeffrey Walton <noloader at gmail.com> wrote:
>> >>
>> >> Hi Everyone,
>> >>
>> >> My program package includes a systemd timer and service. I was able to
>> >> setup my Makefile for a regular install using the daemons web page
>> >> (https://www.freedesktop.org/software/systemd/man/daemon.html).
>> >>
>> >> My question is, how should I handle a staged install using DESTDIR?
>> >> Specifically, should we expect the timer and service to be enabled in
>> >> the staged directory? Should we expect the timer to be started in the
>> >> directory?
>> >
>> > AFAIK, a staged install with $DESTDIR usually means that you're preparing the files to be collected into a package -- usually to be installed on another system and/or at a later time. So it doesn't make practical sense to start anything at this point.
>> >
>> > (And honestly I would **never** expect a Makefile to start any services **at all**. Doesn't matter whether it's staged or not: that is simply not what `make install` does.)
>>
>> Thanks Mantas.
>>
>> Yeah, I know what you mean.
>>
>> > It also doesn't make much sense to call `systemctl enable`, as it's mainly a sysadmin tool. Some distros automatically enable & start services after package installation... but in that case the "enabled" status is still under control by the sysadmin -- it is not hardcoded in the package itself.
>>
>> I think I'm going to add a start: recipe that will enable and start
>> services after install for those who want it. It will be a recipe for
>> non-staged installs.
>>
>> The reasoning is, users want things that "just work". They don't want
>> excuses. A "sudo make start" is a little unusual, but I think it is a
>> better option than the services not starting and users wondering why.
>> I would not want to be the user trying to track down why a
>> [unfamiliar] package does not run as expected.
>
> But if it's unfamiliar to them, why *would* they expect it to be doing something that practically no other package does?
>
> I can see the point if you're aiming this at Debian/Ubuntu users, where the package manager traditionally starts every service as soon as it is installed -- but in that case, it would likely be even simpler to provide your app as a .deb package or PPA as well, rather than making them build from source...

It looks like the problem is (to me), GNU Coding Standards does not
provide guidance on the use case. There is no procedure detailed by
the standard. Confer, the entire standard as a single web page:
https://www.gnu.org/prep/standards/standards.html . The word service
appears once in the context of "long distance telephone service".

Let me ping them and ask them to add a section on Services with both
init and systemd.

Jeff