systemd system unit files and UsrMove

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 11:48 AM, Toshio Kuratomi <a.badger at gmail.com>wrote:

> On Fri, Feb 17, 2012 at 10:46:58AM -0500, Nathaniel McCallum 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.
> >
> > Nathaniel
> >
> > 1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/
> > 2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229
> > 3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777
>
> Yeah -- so I see three options -- move systemd unit files to /usr/share,
> revert /usr/move, change rpmlint (or a fourth -- ignore this warning for
> f17
> and move systemd unit files to /usr/share for f18).
>
> Which are you advocating?


Move systemd unit files to /usr/share and provide simple logic to fall back
/lib, so as not to break upgrades with custom unit files. I am certainly
not advocating a bad user experience. If the schedule doesn't permit it,
I'm ok with delaying the move to /usr/share until f18. However, I would
want to avoid two moves at all costs. I can't imagine moving them to
/usr/shared is a huge task (considering any bugs you would hit would likely
already be hit by UsrMove anyway) or that moving the unit files from /lib
to /usr/share is any different than moving them from /lib to /usr/lib. So
the upgrade experience can't be really harmed by such a move.

Nathaniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120217/f434c36a/attachment.html>