systemd system unit files and UsrMove

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald <h.reindl at thelounge.net>wrote:

>
>
> Am 17.02.2012 18:00, schrieb Nathaniel McCallum:
> > 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.
>
> you are missing the point that /lib/ to /usr/lib is a theoretical
> not invasive change by replacing /lib with a symlink!
>

I'm fine if you want to symlink /usr/lib/systemd/system to
/usr/share/systemd/system or something else comparable. That should be just
as noninvasive. My point is that custom files installed in /lib already
have to be moved to /usr/lib. Why not also cleanly move systemd unit files
to a more standard location?


> moving things around the filesystem means you are breaking
> each sort of scripts and whatever customized software is
> runnign at the users machines - can we please stop to
> enforce permanently chaning paths all over the world for
> some beautniess reason without any technical point for it
>

Well, we've already decided to do these kinds of changes (aka UsrMove). If
we are going to do so, why not do it right? Besides, we already have nice
mechanisms like pkg-config variables to find the right paths for things,
your scripts should use those. And what script is going to break by the
move to /usr/share that won't be broken by the move to /usr/lib when the
proper symlinks are in place?

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