systemd system unit files and UsrMove

[Lennart Poettering]

On Mon, 20.02.12 09:25, Toshio Kuratomi (a.badger at gmail.com) wrote:

> On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
> > On Fri, 17.02.12 10:46, Nathaniel McCallum (nathaniel at natemccallum.com) wrote:
> > 
> > > I'm a fan of systemd [1]. And although I didn't like the fact that unit
> > > files were stored in /lib, I understood the rationale since there was no
> > > /share. However, I've just recently discovered [2] that after UsrMove unit
> > > files will be stored in /usr/lib. Can we not do better than this? And I'd
> > > really rather not work around the problem [3].
> > > 
> > > Seriously, please don't do this.
> > 
> > The unit files are in /lib for a couple of reasons. Firstly, before the
> > /usr merge there was no /share, so we had to place them in
> > /lib. Secondly I think that /lib is actually the better fit for them,
> > simply because I consider them closely related to the code they wrap,
> > and code belongs in lib, libexec or bin. How does that matter? Well, the
> > unit files are very often dependendent on/closely related to the
> > architecture, and make little sense to share them between archs. This
> > applies to a couple of units we ship with systemd itself (for example
> > the hugepages mount unit), but even more often to unit we don't ship
> > ourselves (think mcelog). And distributing these unit files among a
> > number of dirs would seriously suck.
> > 
> This sounds like the unit files belong in %{_libdir} now?  However, that
> would mean that they can't go into noarch packages.  So we probably need to
> know a little more about just how architecture dependent these unit files
> can be.

No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
two different versions for 32bit and 64bit. We want just one, hence they
belong in /lib unconditionally)

Best way to specify the path is %{_unitdir} however, which points to the
actual unit dir, and has been updated for the /usr merge already.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.