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

[Mantas Mikulėnas]

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...

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20191226/4572a34d/attachment.htm>