On 9/10/2011 5:28 PM, Alan McKinnon wrote:
On Sat, 10 Sep 2011 12:19:10 -0400
Michael Mol<mike...@gmail.com> wrote:
On Sat, Sep 10, 2011 at 12:09 PM, Dale<rdalek1...@gmail.com> wrote:
Mick wrote:
From my understanding, the dev is not listening. That is another
thing that bothers me. When devs stop listening to users, that
causes a problem. Remember hal? How many people complained early
From what I read, he's listening, he just isn't being
swayed by the argument. From his perspective, udev "doesn't
support" a split /,/usr because of the arbitrarily complex
udev rules. This is causing users to fill their bug queue
with errors when needed binaries are unavailable at boot,
and thus their hardware doesn't work. Apparently he has
concluded that the number of people who require a separate
/usr partition but cannot use an initramfs is smaller than
the number of people who need udev to have access to all of
/usr.
Unfortunately it appears that he's taking a pretty extreme
approach to solving the problem that will actually *break*
the systems of that second group, which I don't quite
understand the reasoning behind.
As I understand it, nothing of udev itself is in /usr, but instead
packages and scripts which plug themselves into udev to be triggered
by various events.
Perhaps the real solution is to circumvent udev and get those other
packages and scripts to not put hotplug-active files under /usr.
That's my understanding too, and I agree with your conclusions. The
distros can easily (give enough man-power) deal with this too - they
simply have to modify their rpms/debs/pkgs/ebuilds to install specific
identified things to / instead of /usr. They *already* do this for
packages that natively install to peculiar locations.
It would make perfect sense to me for the udev maintainer to
simply declare a split /,/usr "not supported" and let us
deal with the issues. The problem, if I'm reading correctly,
is that he's taken things one step further and decided to
move udev *itself* back into /usr.
Even still, I would think that a Gentoo patchset to revert
the paths back to /lib would be a feasible workaround to
this mess.
--Mike
