systemd system unit files and UsrMove

[Toshio Kuratomi]

On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
> 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)
> 
Okay, so this is one more area where when people mispackage a library and
a program in the same subpackage, they'll get bitten?

Fair enough.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120220/cd60716f/attachment.sig>