Mailing List Archive

On 01/03/2012 10:53 AM, Ian Stakenvicius wrote:
> On 01/01/12 03:53 AM, Sven Vermeulen wrote:
>> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote:
>>> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
>>> understanding is that they want to move software that is installed in
>>> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move
>>> everything from /lib to /usr/lib.
>>
>> I don't like this one bit. Things used to be simple with the "split"
>> between
>> /bin and /usr/bin (and its related directories), this isn't going to
>> make it
>> more simple.
>
> I concurr. I will admit that I've been rather out of touch with what
> other distros are doing (and have been for ~3-4 years), but combining
> everything into /usr/bin just seems plain backwards and I am rather
> shocked that all the distros are moving that way.
>
> Has the LFH been updated?? Googling seems to say no, as the last mod
> seems to have been in 2004... I know that, technically, these are
> 'userspace' programs in that they aren't kernel-space, but they're
> still 'system' programs so to me it still makes sense for them to be
> on the 'system' side of the filesystem hierarchy, doesn't it?
The problem is that one group of developers is ignoring years of history
and purpose in the separation of /bin and /usr/bin and the ability of
having a separate /usr. This is in the udev development team and they
/deliberately/ placed or used some programs in /usr/bin instead /bin and
requiring that /usr bee in the root partition.

I will note that the historical separation of the /usr stems from the
days of user home directories being in /usr/home instead of /home. It
is getting to the point that the security aspects of having a read-only
mount for userspace executables is being overridden by developer fiat.

Lay this one at the RedHat/Fedora developers of udev.

--
G.Wolfe Woodbury
aka redwolfe@gmail.com

On 02/01/12 12:54 PM, William Hubbs wrote:

> The one thing I
> haven't figured out yet is whether it is possible to create an
> initramfs that doesn't have to be updated with every kernel upgrade.

I'm not sure if there is dracut-specific issues that would relate to
this, but the genkernel initramfs (as long as it didn't include any
kernel modules) used to work fine when used against a newer-built
kernel--note though that this was probably not 'supported' behaviour.
So I expect this to be the case with dracut as well.

On 03/01/12 10:10 AM, William Hubbs wrote:

> Unfortunately, it isn't going to be as simple as switching away from
> udev. This move is going to move all software from /bin, /sbin and /lib
> to /usr/bin and /usr/lib. The end result is going to be that regardless
> of whether you are using mdev or udev you will have to use an initramfs
> if /usr is on a separate partition.
>

I don't think anyone's asked this yet:

Do we NEED to deprecate /bin,/sbin,/usr/sbin,/lib ? I realize that
udev/kmod/systemd are moving, but there isn't anything in particular
that would require everything else to move, is there?

I know that there was a compatibility-symlink discussion and in general
it was thought that symlinks would be a bad idea.. but we could, for
anything that would be required in /bin,/sbin for mdev AND /usr/bin for
the new udev,etc (assuming there would actually be overlap, which I
expect there wouldn't be) make the /usr/bin version be a symlink and
keep /bin,/sbin,etc. around.. It would work at least as a temporary
measure, until the new udev/kmod/systemd becomes the de-facto default?



Side note - if /lib is getting moved, does that mean /lib/modules is
moving to /usr/lib/modules too? So kernel modules are no longer on root?

On Tue, 03 Jan 2012 11:08:09 -0500
"G.Wolfe Woodbury" <redwolfe@gmail.com> wrote:

> On 01/03/2012 10:53 AM, Ian Stakenvicius wrote:
> > On 01/01/12 03:53 AM, Sven Vermeulen wrote:
> >> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote:
> >>> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
> >>> understanding is that they want to move software that is
> >>> installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they
> >>> want to move everything from /lib to /usr/lib.
> >>
> >> I don't like this one bit. Things used to be simple with the
> >> "split" between
> >> /bin and /usr/bin (and its related directories), this isn't going
> >> to make it
> >> more simple.
> >
> > I concurr. I will admit that I've been rather out of touch with
> > what other distros are doing (and have been for ~3-4 years), but
> > combining everything into /usr/bin just seems plain backwards and I
> > am rather shocked that all the distros are moving that way.
> >
> > Has the LFH been updated?? Googling seems to say no, as the last
> > mod seems to have been in 2004... I know that, technically, these
> > are 'userspace' programs in that they aren't kernel-space, but
> > they're still 'system' programs so to me it still makes sense for
> > them to be on the 'system' side of the filesystem hierarchy,
> > doesn't it?
> The problem is that one group of developers is ignoring years of
> history and purpose in the separation of /bin and /usr/bin and the
> ability of having a separate /usr. This is in the udev development
> team and they /deliberately/ placed or used some programs in /usr/bin
> instead /bin and requiring that /usr bee in the root partition.

Please, explain to me, how did they do it? As far as I am aware,
autotools installs files where it is told to.

--
Best regards,
Michał Górny

On Tue, Jan 03, 2012 at 11:03:04AM -0500, Ian Stakenvicius wrote:
> On 01/01/12 05:15 AM, Zac Medico wrote:
> >
> > Overall, a migration like this should go pretty smoothly as long as
> > people with separate /usr take appropriate actions to make sure their
> > systems will boot. People without separate /usr can basically relax and
> > enjoy the ride.
>
>
> If a separate /usr is the only holdback, would it not be possible to
> simply add static devnodes to the pre-udev /dev , and make a pre-init
> wrapper script that mounts /usr ?

I've thought about this, but a wrapper script assumes that the things it
needs are still available in /, so any wrapper script we make will break
as soon as something it needs migrates to /usr. For example, consider
what happens when bash or all of coreutils migrate to /usr.

William

On 03-01-2012 10:51:00 -0600, William Hubbs wrote:
> > If a separate /usr is the only holdback, would it not be possible to
> > simply add static devnodes to the pre-udev /dev , and make a pre-init
> > wrapper script that mounts /usr ?
>
> I've thought about this, but a wrapper script assumes that the things it
> needs are still available in /, so any wrapper script we make will break
> as soon as something it needs migrates to /usr. For example, consider
> what happens when bash or all of coreutils migrate to /usr.

Do you mean us, or upstream?
I don't think bash or coreutils do that. We explicitly configure them
with --prefix=/ or move some utils back and forth.


--
Fabian Groffen
Gentoo on a different level

On 03/01/12 11:51 AM, William Hubbs wrote:

> For example, consider
> what happens when bash or all of coreutils migrate to /usr.
>


..well, when /bin/sh no longer exists then there -will- be issues,
system-wide, on a massive scale. Unless shells or environments can
dynamically map that hash-bang to an appropriate interpreter (ie,
themselves) automatically.

*shudder*.. I don't even want to think about the migration i'd have to
do to handle that change.

Ian Stakenvicius posted on Tue, 03 Jan 2012 12:03:32 -0500 as excerpted:

> On 03/01/12 11:51 AM, William Hubbs wrote:
>
>> For example, consider what happens when bash or all of coreutils
>> migrate to /usr.
>
> ..well, when /bin/sh no longer exists then there -will- be issues,
> system-wide, on a massive scale. Unless shells or environments can
> dynamically map that hash-bang to an appropriate interpreter (ie,
> themselves) automatically.
>
> *shudder*.. I don't even want to think about the migration i'd have to
> do to handle that change.

FWIW, I was reading a review of [.was it GOBO Linux?, some distro that's
famous for reorganizing things much like MS does, a program files dir,
etc], and it was said to still contained a /bin with only a couple
symlinks, /bin/bash and /bin/sh, for this very reason.

Of course fedora uses an initr* so real-root and /usr will be mounted at
the same time, and they're doing a /bin -> /usr/bin symlink at least for
now, so they don't need to worry about that in the short term either.
Longer term, possibly they'll try to get rid of it, but I expect at least
some form of /bin/sh and/or /bin/bash symlink to remain around for quite
some time.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Ian Stakenvicius posted on Tue, 03 Jan 2012 10:53:45 -0500 as excerpted:

> Has the LFH been updated?? Googling seems to say no, as the last mod
> seems to have been in 2004...

That was covered here in the last discussion. The FHS and LSB are
getting updated too, with the people driving the update being the very
same people, the fedora/redhat folks behind udev/udisks/upower/dbus/
systemd/etc, with gnome as well now talking about a "gnomeos" that
integrates and requires the whole set, plus X (or whatever the X
successor is called, I forgot ATM) and gnome, of course, so that future
gnome will assume systemd, etc, as well.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Tue, Jan 3, 2012 at 11:08 AM, G.Wolfe Woodbury <redwolfe@gmail.com> wrote:
>  It
> is getting to the point that the security aspects of having a read-only
> mount for userspace executables is being overridden by developer fiat.
>

Can you clarify what you mean by this? I think the whole reason that
RedHat is doing this is so that they can make /usr read-only, so that
it only changes when you perform upgrades. I imagine the next step
would be to use a trusted boot path and verify that partition when it
is mounted.

FHS has been brought up - I suspect the upstream projects that are
sparking this move are quite aware that they're breaking compliance,
so I doubt they're going to care if you file bugs pointing this out.
No doubt after the change is made they'll lobby to revise FHS, and at
that point since everybody will have gone along with it already there
won't be much point in voicing objection.

As with anything in FOSS - whoever has the developers gets to decide
how things work. Anybody can file bugs or post on mailing lists, but
the people writing the code will do what they do...

Rich

On Tue, Jan 03, 2012 at 05:35:51PM +0000, Duncan wrote:
> Ian Stakenvicius posted on Tue, 03 Jan 2012 12:03:32 -0500 as excerpted:
>
> > On 03/01/12 11:51 AM, William Hubbs wrote:
> >
> >> For example, consider what happens when bash or all of coreutils
> >> migrate to /usr.
> >
> > ..well, when /bin/sh no longer exists then there -will- be issues,
> > system-wide, on a massive scale. Unless shells or environments can
> > dynamically map that hash-bang to an appropriate interpreter (ie,
> > themselves) automatically.
> >
> > *shudder*.. I don't even want to think about the migration i'd have to
> > do to handle that change.
>
> FWIW, I was reading a review of [.was it GOBO Linux?, some distro that's
> famous for reorganizing things much like MS does, a program files dir,
> etc], and it was said to still contained a /bin with only a couple
> symlinks, /bin/bash and /bin/sh, for this very reason.
>
> Of course fedora uses an initr* so real-root and /usr will be mounted at
> the same time, and they're doing a /bin -> /usr/bin symlink at least for
> now, so they don't need to worry about that in the short term either.
> Longer term, possibly they'll try to get rid of it, but I expect at least
> some form of /bin/sh and/or /bin/bash symlink to remain around for quite
> some time.

Yes, the symlinks will be around for some time for this reason, but,
/bin/sh will point to /usr/bin/bash, so you have the same affect if /usr
is not mounted since the symlink can't be resolved.

William

Ian Stakenvicius posted on Tue, 03 Jan 2012 11:40:02 -0500 as excerpted:

> Side note - if /lib is getting moved, does that mean /lib/modules is
> moving to /usr/lib/modules too? So kernel modules are no longer on
> root?

Yes. Again, the whole thing is being designed from the perspective of a
binary distro which already uses an initr* to handle loading the modules
necessary for mounting real-root, and from that perspective, all they're
doing is having it handle /usr in the same way, mounting it right after
real-root in early-init, before control switches to it from the initr*.

The set of folks behind this don't particularly care about anyone doing
it a different way, which they consider Unix legacy, just as they
consider the BSDs, etc, legacy, integrating Linux-only solutions and
refusing to hold up "progress" (as they view it) just because someone
else can't keep up.

What we're really seeing now is the effect of letting RedHat with its
paid developers be the core behind so many core Linux systems, forcing
udev, systemd, /usr-as-the-new-root, etc, down everyone else's throats
because they can, because the entire community is so dependent on RedHat
(with Ubuntu and SuSE as well for some but not all of it) and its devs
and its money that it's no longer feasible for anyone else to fork all
the core programs RedHat devs lead on, and keep up. Sure, they could be
forked, but the forks would be left with few enough resources it'd be
like xfree86, they might still be there but in a few years they'd be
forgotten about by the rest of the community... One project, not a
problem, all of them together, just not feasible.

What about when glibc also begins to assume everything's in /usr/? ...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On 03/01/12 12:45 PM, Duncan wrote:
> Ian Stakenvicius posted on Tue, 03 Jan 2012 10:53:45 -0500 as excerpted:
>
>> Has the LFH been updated?? Googling seems to say no, as the last mod
>> seems to have been in 2004...
>
> That was covered here in the last discussion. The FHS and LSB are
> getting updated too, with the people driving the update being the very
> same people, the fedora/redhat folks behind udev/udisks/upower/dbus/
> systemd/etc, with gnome as well now talking about a "gnomeos" that
> integrates and requires the whole set, plus X (or whatever the X
> successor is called, I forgot ATM) and gnome, of course, so that future
> gnome will assume systemd, etc, as well.
>

FHS, thank you. I didn't think I had that acronym right...


OK, well, if this is becoming the official standard then we will
definitely need to adhere to it; I guess it's just a matter of when and
what contingency/update plans we want to use to do it..

... if Gentoo's installed on a system (regardless of platform, and
leaving out the Prefix installs), the filesystem is up to gentoo right?
ie, there wouldn't be a need for a particular platform to stick with
FHS-2.3 would there? Once we migrate to FHS-3.0, we can migrate all
archs and profiles at the same time?

On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote:
> I don't think anyone's asked this yet:
>
> Do we NEED to deprecate /bin,/sbin,/usr/sbin,/lib ? I realize that
> udev/kmod/systemd are moving, but there isn't anything in particular
> that would require everything else to move, is there?

Well, I don't think everything is going to move immediately. The way I
see this happening is, udev/systemd/kmod are moving first, then other
upstreams will move their software.

If we don't move with them, I'm afraid that we will have more and more
customizations to maintain, either in the form of ebuilds using custom
build options, or maybe even software patches if programs operate with
the assumption that they are installed in /usr.

> I know that there was a compatibility-symlink discussion and in general
> it was thought that symlinks would be a bad idea.. but we could, for
> anything that would be required in /bin,/sbin for mdev AND /usr/bin for
> the new udev,etc (assuming there would actually be overlap, which I
> expect there wouldn't be) make the /usr/bin version be a symlink and
> keep /bin,/sbin,etc. around.. It would work at least as a temporary
> measure, until the new udev/kmod/systemd becomes the de-facto default?

Hmm, I'm not really interested in putting symbolic links in /usr/bin
linking to things in /bin or /sbin. I'm not following what that does for
us.

> Side note - if /lib is getting moved, does that mean /lib/modules is
> moving to /usr/lib/modules too? So kernel modules are no longer on root?

This is an interesting question. I haven't heard one way or the other
what is happening with /lib/modules.

William

Hi,

On Mon, 2012-01-02 at 10:41 +0200, Eray Aslan wrote:
> On 2012-01-01 11:50 PM, Olivier Crête wrote:
> > systemd/dracut/etc handles /usr on its own filesystem just fine. What is
> > required is that /usr must be mounted before the pivot_root away from
> > the initramfs.
>
> RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and
> udev. Udev was probably salvagable before systemd but noone has the
> motivation or the man-power to manage the huge delta that would result
> now. It would probably amount to forking udev. So people are following
> along even if they are unhappy.

This is completely unrelated to RPMs. And udev was not developed by
RedHat, but by a Gentoo developer who works for Suse, then it was
maintained by a Suse dev who just very recently joined RedHat.

> Plus Redhat did not support in-place upgrades last time I checked. So
> they don't really care for a lot of problems that are important for us.

There is a good reason for that, because in-place upgrades are
impossible to do safely (and RedHat customers don't accept weird
breakages like Gentoo users do). For example, if you replace a library
or even a resource file (like a .ui file for GtkBuilder), the only way
to make it work is to make sure that no currently running application is
using it. And that just can't happen with system libraries like glibc or
system packages like udev or dbus. So the only safe way to upgrade those
is to reboot.

> Regarding the original question, I belive there are 2 issues here:
> 2. Migrating /bin to /usr/bin, /sbin to /usr/sbin etc.
>
> For the second point, we should hold on as long as we deem appropriate.
> Then reconsider and -most probably- move ahead with the migration. Main
> point is not to break existing installations by making the move too
> quickly. Give sysadmins time to to adjust, resize partitions if
> necessary etc. Do not go for half way solutions (i.e. number 2 in the
> original email).

I don't see what breakage would be caused by a big-bang update (move
everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
doubt any system has a /usr so tight that adding the couple things that
are in / to /usr/bin would break it.. Btw, this also includes /lib*
to /usr/lib*.


--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Tue, 03 Jan 2012 13:50:25 -0500
Olivier Crête <tester@gentoo.org> wrote:
> There is a good reason for that, because in-place upgrades are
> impossible to do safely (and RedHat customers don't accept weird
> breakages like Gentoo users do). For example, if you replace a library
> or even a resource file (like a .ui file for GtkBuilder), the only way
> to make it work is to make sure that no currently running application
> is using it. And that just can't happen with system libraries like
> glibc or system packages like udev or dbus. So the only safe way to
> upgrade those is to reboot.

Uhm... Unix filesystems don't work that way; you can unlink an open file
and anything that has that file still opened will continue to work.
You're thinking of Windows; Unix supports in-place upgrades just fine.

--
Ciaran McCreesh

On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
> I don't see what breakage would be caused by a big-bang update (move
> everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
> doubt any system has a /usr so tight that adding the couple things that
> are in / to /usr/bin would break it.. Btw, this also includes /lib*
> to /usr/lib*.

I think the best way to do this part of it is going to be to just follow
the upstream packages. When they release a new version that installs in
/usr, just allow that to happen. Eventually there will be very little in
/{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
/bin/sh.

I am not for what fedora is doing with the
/bin->/usr/bin, /sbin->/usr/sbin and /lib->/usr/lib symlinks.

William

On Tue, 3 Jan 2012 18:54:27 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 03 Jan 2012 13:50:25 -0500
> Olivier Crête <tester@gentoo.org> wrote:
> > There is a good reason for that, because in-place upgrades are
> > impossible to do safely (and RedHat customers don't accept weird
> > breakages like Gentoo users do). For example, if you replace a
> > library or even a resource file (like a .ui file for GtkBuilder),
> > the only way to make it work is to make sure that no currently
> > running application is using it. And that just can't happen with
> > system libraries like glibc or system packages like udev or dbus.
> > So the only safe way to upgrade those is to reboot.
>
> Uhm... Unix filesystems don't work that way; you can unlink an open
> file and anything that has that file still opened will continue to
> work. You're thinking of Windows; Unix supports in-place upgrades
> just fine.

Considering that all applications keep all files open just for the fun
of it.

--
Best regards,
Michał Górny

On 03-01-2012 13:02:55 -0600, William Hubbs wrote:
> On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
> > I don't see what breakage would be caused by a big-bang update (move
> > everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
> > doubt any system has a /usr so tight that adding the couple things that
> > are in / to /usr/bin would break it.. Btw, this also includes /lib*
> > to /usr/lib*.
>
> I think the best way to do this part of it is going to be to just follow
> the upstream packages. When they release a new version that installs in
> /usr, just allow that to happen. Eventually there will be very little in
> /{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
> /bin/sh.

What packages would that be? If you're thinking about coreutils, just
trim down the ebuild by not moving some of the tools to /bin. Our
ebuild makes it conform to FHS, not the coreutils buildsystem itself.


--
Fabian Groffen
Gentoo on a different level

On Tue, 2012-01-03 at 12:36 -0600, William Hubbs wrote:
> On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote:
> > Side note - if /lib is getting moved, does that mean /lib/modules is
> > moving to /usr/lib/modules too? So kernel modules are no longer on root?
>
> This is an interesting question. I haven't heard one way or the other
> what is happening with /lib/modules.

I doubt the kernel will move its install location, they're a very
conservative bunch. But I heard that kmod will start looking for modules
in /usr/lib/modules ...

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Tue, 2012-01-03 at 13:02 -0600, William Hubbs wrote:
> On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
> > I don't see what breakage would be caused by a big-bang update (move
> > everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
> > doubt any system has a /usr so tight that adding the couple things that
> > are in / to /usr/bin would break it.. Btw, this also includes /lib*
> > to /usr/lib*.
>
> I think the best way to do this part of it is going to be to just follow
> the upstream packages. When they release a new version that installs in
> /usr, just allow that to happen. Eventually there will be very little in
> /{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
> /bin/sh.
>
> I am not for what fedora is doing with the
> /bin->/usr/bin, /sbin->/usr/sbin and /lib->/usr/lib symlinks.

At least the upstreams that work for RedHat and Suse (and that's almost
all system packages) will come to expect that these symlinks exist. For
example, I just heard that kmod will expect kernel modules
in /usr/lib/modules even though the kernel installs them
in /lib/modules.. So yes, upstream will force these symlinks on us too.

A couple years ago, Gentoo was the forward looking distribution, ready
to try radical changes that break existing assumption, like our init
scripts with dependencies or our early use of udev. These days, I see so
much resistance to progress, it makes me sad.


--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Tue, Jan 3, 2012 at 1:36 PM, William Hubbs <williamh@gentoo.org> wrote:
> Well, I don't think everything is going to move immediately. The way I
> see this happening is, udev/systemd/kmod are moving first, then other
> upstreams will move their software.

Agreed. If only a few packages have issues we don't have to subject
our users to a huge overnight change. We can just move gradually with
upstream.

> Hmm, I'm not really interested in putting symbolic links in /usr/bin
> linking to things in /bin or /sbin. I'm not following what that does for
> us.

Perhaps we could consider compatibility packages, like a bash-links
that just installs a symlink to /usr/bin/bash in /bin. Ideally we'd
never create them, but if a package can't be fixed in a
straightforward way we could add a link package and then have that
package depend on it. Then we can get rid of those links over time as
nothing depends on them when upstream catches up.

Before anything changes at all we need to have a solution in
dracut/etc for mounting /usr. Once that is in place packages can move
at any pace we wish, so there is no reason to short-cut QA.

Rch

On 03-01-2012 14:19:22 -0500, Olivier Crête wrote:
> On Tue, 2012-01-03 at 12:36 -0600, William Hubbs wrote:
> > On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote:
> > > Side note - if /lib is getting moved, does that mean /lib/modules is
> > > moving to /usr/lib/modules too? So kernel modules are no longer on root?
> >
> > This is an interesting question. I haven't heard one way or the other
> > what is happening with /lib/modules.
>
> I doubt the kernel will move its install location, they're a very
> conservative bunch. But I heard that kmod will start looking for modules
> in /usr/lib/modules ...

Seems they just made it a configure argument though [1].


[1] http://git.profusion.mobi/cgit.cgi/kmod.git/commit/?id=a308abec371364eec8344681cfe1fb50d624e43e

--
Fabian Groffen
Gentoo on a different level

2012/1/3 Olivier Crête <tester@gentoo.org>:
> A couple years ago, Gentoo was the forward looking distribution, ready
> to try radical changes that break existing assumption, like our init
> scripts with dependencies or our early use of udev. These days, I see so
> much resistance to progress, it makes me sad.

I think the key is to keep huge changes optional to start with. This
one feels like it is being pushed upon us.

I don't really have a big problem with moving to /usr and all that.
However, I do have some concerns with the larger direction that
everybody is taking with vertical integration (which this is just a
part of). For example, if eventually you can't run gnome without
systemd where does that leave bsd gentoo users? Gentoo is about
choice, and various upstream efforts are moving in the direction of
giving users only one choice - take it or leave it. How do you
install KDE and Gnome on the same system when they eventually want
different sysvinit implementations. Will the RedHat and Ubuntu of the
future have no more in common than Tivo and Android do today?

Rich

On Tue, Jan 03, 2012 at 02:19:39PM -0500, Olivier Crête wrote:
> On Tue, 2012-01-03 at 13:02 -0600, William Hubbs wrote:
> > On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
> > > I don't see what breakage would be caused by a big-bang update (move
> > > everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
> > > doubt any system has a /usr so tight that adding the couple things that
> > > are in / to /usr/bin would break it.. Btw, this also includes /lib*
> > > to /usr/lib*.
> >
> > I think the best way to do this part of it is going to be to just follow
> > the upstream packages. When they release a new version that installs in
> > /usr, just allow that to happen. Eventually there will be very little in
> > /{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
> > /bin/sh.
> >
> > I am not for what fedora is doing with the
> > /bin->/usr/bin, /sbin->/usr/sbin and /lib->/usr/lib symlinks.
>
> At least the upstreams that work for RedHat and Suse (and that's almost
> all system packages) will come to expect that these symlinks exist. For
> example, I just heard that kmod will expect kernel modules
> in /usr/lib/modules even though the kernel installs them
> in /lib/modules.. So yes, upstream will force these symlinks on us too.

I just looked at the commit in kmod for this. It can be worked around
with a ./configure switch until the kernel switches their install
location, so they aren't forcing this one.

William