From: Daniel Campbell <lists@sporkbox.us>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] some of the stuff in /usr that's become a problem
Date: Sun, 29 Sep 2013 21:21:01 -0500 [thread overview]
Message-ID: <5248E00D.6010006@sporkbox.us> (raw)
In-Reply-To: <5248DBDF.2070902@gmail.com>
On 09/29/2013 09:03 PM, Greg Woodbury wrote:
> One of the most obvious things that broke booting with a seperate /usr
> is not GNOMEs fault, but GRUB 2's fault.
>
> the move of /bin to /usr/bin (for things like cp,mv,ln,ls) came after
> the breakage of /usr, but is symptomatic of some distros cavalier
> attitudes to the problem.
>
> /usr/lib/udev.....
> /usr/lib/systemd.....
>
> were both placed in /usr despite objections from a number of folks.
>
> So claims that udev and systemd are not responsible are not true.
>
> /usr/lib/e2initrd-helper was placed in /usr despite objections.
> /usr/lib/libdevmapper* was moved despite objections...
> /usr/lib/liblvm2* helpers were placed in /usr despite objections...
>
> There were deliberate placements of "new" or updated libraries in /usr
> that were known ahead of time that would break the use of a separate
> /usr filesystem.
>
> It was pointed out quite plainly at the time, and the placements were
> made anyway, dismissing the concerns are "mere historical artifacts" or
> "clinging to ancient and outmoded traditions."
>
> The *same things* are still being cited (about being outmoded) in
> dismissing concers about forcing useres to adopt technologies they do
> not want to use.
>
I agree with you but I think the distinction made on udev and systemd is
that their *upstreams* didn't suggest they go in /usr. I don't know for
sure since I don't follow systemd and frankly detest it, but if they
said systemd and udev belong in /bin or somesuch, then they can't be
held responsible. The responsibility for that decision falls on the
maintainers, but it's compounded by the dependencies of systemd/udev.
They depend on dbus, which resides in /usr. Was that an upstream
decision or a distro decision? If we follow this dependency tree of /usr
moves, which package was the first to migrate to /usr and begin this
problem? The move to /usr was a social one that started years ago, not a
technical decision made this year. The issue right now is damage control
and, for some, maybe taking a good look at the FHS and deciding what
really makes sense.
next prev parent reply other threads:[~2013-09-30 2:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-30 2:03 [gentoo-user] some of the stuff in /usr that's become a problem Greg Woodbury
2013-09-30 2:21 ` Daniel Campbell [this message]
2013-09-30 3:13 ` William Hubbs
2013-09-30 3:40 ` Daniel Campbell
2013-10-01 8:36 ` Greg Woodbury
2013-10-01 8:30 ` Greg Woodbury
2013-10-01 8:45 ` Alan McKinnon
2013-09-30 2:51 ` [gentoo-user] " »Q«
2013-09-30 8:10 ` [gentoo-user] " Neil Bothwick
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=5248E00D.6010006@sporkbox.us \
--to=lists@sporkbox.us \
--cc=gentoo-user@lists.gentoo.org \
/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