From: Clemens Gruber <clemens.gruber@pqgruber.com>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] /usr merge
Date: Wed, 12 Apr 2017 15:36:51 +0200 [thread overview]
Message-ID: <20170412133651.GA3994@archie.localdomain> (raw)
In-Reply-To: <4319211d-1327-0285-b304-0fed01823a8b@gr13.net>
On Wed, Apr 12, 2017 at 02:36:58PM +0200, Enrico Weigelt, metux IT consult wrote:
> I just dont remember any case where some package expects a program in
> /usr/bin, which traditionally is in /bin. But there're cases in the
> opposite direction, eg. the recent busybox-tar issue here on the list.
I recently experienced this when using some tools from coreutils instead
of busybox.
The Fedora folks made a good case for the usr merge, here:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
ArchLinux did the /usr merge four years ago, and I really like the idea
of no longer needing to know for each binary, where it was put.
It is especially useful when writing systemd units because ExecStart
needs the full path.
I can remember several problems which would not have happened with a
usr merge. Most of them wrong paths in ExecStart(Pre), because for
example coreutils rm is installed to /usr/bin while busybox rm is in
/bin.
Does someony have a system in production, where PTXdist is updated
somewhat regularily and the usr split is required / using an initrd is
not possible?
Thanks,
Clemens
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
next prev parent reply other threads:[~2017-04-12 13:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 10:07 Michael Olbrich
2017-04-12 8:27 ` Enrico Weigelt, metux IT consult
2017-04-12 9:24 ` Michael Olbrich
2017-04-12 12:06 ` Ladislav Michl
2017-04-12 12:36 ` Enrico Weigelt, metux IT consult
2017-04-12 13:36 ` Clemens Gruber [this message]
2017-04-12 18:42 ` Alexander Dahl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170412133651.GA3994@archie.localdomain \
--to=clemens.gruber@pqgruber.com \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox