On 2013-04-01, Michael Mol <mike...@gmail.com> wrote: > > On 04/01/2013 03:26 PM, William Hubbs wrote: > >> You know that both udev and eudev have exactly the same issue with >> separate /usr right? >> The problem there isn't in the udev code, but it has to do with what is >> happening in rules that other packages install. > > As I recall, the problem is where the ebuild choses to install the code. > Putting the udev code under /usr forces the issue on systems where it > would otherwise not be an issue. > > Putting the udev code under / avoids that issue, but opens up the system > to the "silently fail" thing upstream liked to use as the basis of > "separate /usr is broken" > > So, there are three conceivable configurations (initramfs notwithstanding): > > 1. With systems which don't require /usr binaries before /usr would be > mounted, separate /usr is not a problem. > > 2. With systems which require /usr binaries for some features before > /usr would be mounted, those features will silently fail. > > 3. With systems which require /usr binaries to mount /usr, all hell > breaks loose. > > Putting the udev code under /usr moves all udev systems from group 2 > into group 3. In a sense, this fixes those systems because the admin is > forced to address the silent failures he was previously unaware of. It > also means pissing off a bunch of people who had features silently > failing...but they probably didn't know or care about those features in > the first place. > > It also moves all systems from group 1 into group 3...which is simply wro= > ng. > > So long as eudev keeps its install path at / instead of /usr, admins in > group 1 will probably be perfectly happy.
I'd guess nothing prevents the udev ebuild from doing so, too. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
