[syslog-ng] [Bug 126] [systemd] Add installation of systemd unit file via build-sys

[bugzilla at bugzilla.balabit.com]

https://bugzilla.balabit.com/show_bug.cgi?id=126


Balazs Scheidler <bazsi at balabit.hu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|                            |FIXED
             Status|NEW                         |RESOLVED




--- Comment #9 from Balazs Scheidler <bazsi at balabit.hu>  2011-07-01 16:29:47 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Hmm.. I've found this description:
> > 
> > https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Daemon
> > 
> > It states that:
> > 
> > "At the build installation time (e.g. make install during package build) packages are recommended to 
> > install their systemd unit files in the directory returned by pkg-config systemd 
> > --variable=systemdsystemunitdir (for system services), resp. pkg-config systemd 
> > --variable=systemdsessionunitdir (for session services). This will make the services 
> > available in the system on explicit request but not activate them automatically during 
> > boot. Optionally, during package installation (e.g. rpm -i by the administrator) 
> > symlinks should be created in the systemd configuration directories via the enable 
> > command of the systemctl(1) tool, to activate them automatically on boot. "
> > 
> > I'm not sure I agree, however I wouldn't want to create a non-standard option, 
> > that looks like a standard one.
> 
> Forgive me, I'm not sure what your concern is here, other than the awkward naming
> convention.

I was just writing down my thoughts. The thing was:

I didn't quite agree to install service file from a .tar.gz installation into 
/lib/systemd/system, I've figured that tarball installation is more similar to installing
a home-grewn script, therefore the defaults should go to /etc/systemd/system as if the
user was doing it on her own.

But going directly against documented "best practice" is not a good idea: 
creating a standard (--with-systemdsystemunitdir) option, which would have 
a different default than the documented best practice is sure to invite confusion.

But anyway, with the change in option processing to only do installation if
the user explicitly requests it, my concern is gone.

> 
> > I have another concern: if systemd is present on the system, and my development 
> > computer would support it, then the Makefiles would try to install it unconditionally to
> > /lib/systemd/system, which would cause permission denied errors, since I'm doing 
> > development as a non-root user.
> 
> Are you saying that a make install command such as the below ignores DESTDIR?
> 
>   make DESTDIR=/path/to/dev/root install
> 
> I can't reproduce this, regardless of the value passed to --with-systemdsystemunitdir.
> DESTDIR is definitely honored both using your patch and mine.

No, but I'm not using DESTDIR when doing development. I simply "make install" to a 
$HOME relative prefix, but since systemd unit dir is ignoring $prefix (which it 
should be doing), the unit file would be copied to /lib/systemd/system, even if 
I wasn't the root user.

> 
> > Also, the hooks you used don't support "make uninstall", which automake otherwise does.
> 
> That's my lack of experience with autotools showing through. Completely unintended.

No problem :)

> 
> > Here's the currently experimental patch I've came up with, which:
> >   * does nothing with the unit file by default
> >   * if --with-systemdsystemunitdir is specified without arguments, it tries to autodetect it using pkg-config
> >   * if --without-systemdsystemunitdir is specified, it does nothing
> >   * if --with-systemdsystemunitdir is specified with an argument, it uses that directory
> 
> Awesome. With the currently advertised autotools macro, specifying no argument to
> --with-ssud (getting tired of typing that) will result in no units being installed.

ok.

> 
> > Can you please check if this works for you? Also, can you please voice my concerns 
> > about the suggested implementation to the systemd developers? Thanks.
> > 
> > Here's the patch currently (not yet on master):
> > 
> > http://git.balabit.hu/?p=bazsi/syslog-ng-3.3.git;a=shortlog;h=systemd-unit-install
> > 
> 
> This is great, and it does work for me. 

Thanks.  Committed for 3.3:

commit db89491b07e2d6541a52b8ea75a5153d2c28f0a9
Author: Balazs Scheidler <bazsi at balabit.hu>
Date:   Fri Jul 1 16:24:57 2011 +0200

    add support for installing systemd unit files

    This patch adds a standard --with-systemdsystemunitdir configure option
    that:

      * without explicit options it does nothing with the unit file
      * if --with-systemdsystemunitdir is specified without arguments,
        it tries to autodetect the path using pkg-config
      * if --without-systemdsystemunitdir is specified, it does nothing
      * if --with-systemdsystemunitdir is specified with an argument, it
        uses that directory to install the unit file into


    Signed-off-by: Dave Reisner <dreisner at archlinux.org>
    Signed-off-by: Balazs Scheidler <bazsi at balabit.hu>


> Just curious though, could this a candidate for backport to 3.2, or is it too big
> of a change to be considered for a stable release?

I've backported it to the 3.2 tree, can you please check if it works there too? There 
was a minor conflict, but I resolved it.

Thanks.

commit e2961e1c738c8b02ca6057ac34415536830dd0e9
Author: Balazs Scheidler <bazsi at balabit.hu>
Date:   Fri Jul 1 16:28:02 2011 +0200


-- 
Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.