Mailing List Archive

On Sun, 2012-01-01 at 14:51 -0600, Dale wrote:
> Olivier Crête wrote:
> > On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote:
> >> On Sun, 01 Jan 2012 02:12:22 -0500
> >> Olivier Crête<tester@gentoo.org> wrote:
> >> All of my systems currently have a seperate /usr that is mounted at
> >> boot. Unfortunately I do agree that this is not something that we can
> >> fight. This was brought up earlier and the only thing we can do
> >> for people like myself (who mount /usr at boot) is to create a simple
> >> initramfs that only has the purpose of mounting /usr at boot. The main
> >> thing I don't like about initramfs is that we have to regenerate it any
> >> time we update the packages that get included in it.
> > That's why you have dracut to do it for you.
> >
> >
>
> Which is keyworded at this point. Stable users do what?

This is a discussion about the future... Changing keywords is trivial if
we care.

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

On Sun, 2012-01-01 at 20:23 +0000, Ciaran McCreesh wrote:
> On Sun, 01 Jan 2012 15:21:24 -0500
> Olivier Crête <tester@gentoo.org> wrote:
> > Honestly, so many things just work on MacOS and just need hours of
> > tweaking for us..
>
> The problem with "just works" is that when it breaks, it can't be
> fixed. Not being able to handle /usr on its own filesystem is a perfect
> example of this.

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.

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

On Sun, Jan 01, 2012 at 02:12:22AM -0500, Olivier Crête wrote:
> The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and
> unmaintained upstream shows that even a relatively large
Why do you say that OpenRC is unmaintained upstream? OpenRC is actively
maintained in Gentoo, with the largest contributors being WilliamH,
vapier, idl0r and myself.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:

> On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
>> I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
>> deleted.
>>
>> However, what I would like to see is that the package maintainers would
>> be responsible for creating any compatibility symlinks their package
>> needs, not portage. I don't think it is a good idea to have portage or
>> any package manager controling the migration.
>
> The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
> then create symlinks from the other dirs to /usr/bin.. That can be done
> in big move, it's the way Fedora is going to do it.

That's what I had in mind, and in fact have already been thinking about
trying, here.

Which is why I don't really like the idea of packages placing symlinks,
since then it'd likely be the symlink copied last, overwriting the actual
binary with the symlink... pointing at itself due to the symlinked dirs!

Which is why I suggested a portage feature that would detect such
collisions and die before installing them, potentially overwriting the
binary with a symlink to itself!

--
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 Sun, Jan 1, 2012 at 8:59 AM, William Hubbs <williamh@gentoo.org> wrote:
> Udev, kmod (which is a replacement for module-init-tools which will be needed
> by >=udev-176), systemd, and soon others, are advocating a major change
> to the locations where binaries and libraries are stored on linux
> systems.

Could you please point me to the discussions where udev, kmod and soon
others are advocating /usr/bin and /bin unification?
--
Duy

On 01/01/2012 09:39 PM, Duncan wrote:
> Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
>
>> On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
>>> I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
>>> deleted.
>>>
>>> However, what I would like to see is that the package maintainers would
>>> be responsible for creating any compatibility symlinks their package
>>> needs, not portage. I don't think it is a good idea to have portage or
>>> any package manager controling the migration.
>>
>> The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
>> then create symlinks from the other dirs to /usr/bin.. That can be done
>> in big move, it's the way Fedora is going to do it.
>
> That's what I had in mind, and in fact have already been thinking about
> trying, here.
>
> Which is why I don't really like the idea of packages placing symlinks,
> since then it'd likely be the symlink copied last, overwriting the actual
> binary with the symlink... pointing at itself due to the symlinked dirs!
>
> Which is why I suggested a portage feature that would detect such
> collisions and die before installing them, potentially overwriting the
> binary with a symlink to itself!

It should not be a problem because merge of symlinks is automatically
delayed in cases when the symlink target doesn't exist yet. There's a
loop where it merges as many regular files as it can, and if there are
any symlinks that can't be resolved then it merges them after all the
regular files have been merged.
--
Thanks,
Zac

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.

Nitpick: I don't think pivot_root is used anymore. It is basically
unlink, mount, chroot and exec now (i.e. switch_root).

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.

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.

Regarding the original question, I belive there are 2 issues here:
1. Requiring initramfs (or dracut or whatever) for separate /usr
2. Migrating /bin to /usr/bin, /sbin to /usr/sbin etc.

For the first point, we should start requiring initramfs of some sort
for separate /usr now. That train has passed.

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).

As a side note, thank you and keep up your good work on OpenRC. I find
it is easier, cleaner and in general superior to systemd especially in
server settings. And for my laptop, I don't really care which init
system is used anyway.

--
Eray Aslan <eras@gentoo.org>

On Mon, 2 Jan 2012 13:24:00 +0700
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:

> On Sun, Jan 1, 2012 at 8:59 AM, William Hubbs <williamh@gentoo.org>
> wrote:
> > Udev, kmod (which is a replacement for module-init-tools which will
> > be needed by >=udev-176), systemd, and soon others, are advocating
> > a major change to the locations where binaries and libraries are
> > stored on linux systems.
>
> Could you please point me to the discussions where udev, kmod and soon
> others are advocating /usr/bin and /bin unification?

I think he meant 'kmod doesn't provide hacks necessary to installs to
two roots at once'.

--
Best regards,
Michał Górny

On Sun, Jan 01, 2012 at 03:21:47PM -0500, Olivier Crête wrote:
> > But if people really want to focus on initramfs, I'd appreciate some
> > documentation help on it. Not only on how to create one, but also why it is
> > necessary, how to manage initramfs'es, the concepts underlying, etc.
>
> Short version: use dracut.

And how does dracut know which files it needs to mount my /usr?

Wkr,
Sven Vermeulen

On Mon, Jan 2, 2012 at 6:47 AM, Sven Vermeulen <swift@gentoo.org> wrote:
> And how does dracut know which files it needs to mount my /usr?

I assume based on the selection of modules that you enabled when
building/running it.

I believe dracut builds static binaries, so it mainly needs updating
when you build a new kernel.

Of course, right now dracut won't mount your /usr in any case, so it
needs to be improved.

Rich

On 3 January 2012 01:58, Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jan 2, 2012 at 6:47 AM, Sven Vermeulen <swift@gentoo.org> wrote:
> > And how does dracut know which files it needs to mount my /usr?
>
> I assume based on the selection of modules that you enabled when
> building/running it.
>
> I believe dracut builds static binaries, so it mainly needs updating
> when you build a new kernel.
>
>
It also takes a list of filesystem types to add support for mounting , and
copies the mount.* binaries across to the tmpfs root image, along with any
dependencies.

May help to understand if you see the listing of the cpio'd archive:
https://gist.github.com/1550652

Its sort of magical really.

You'll note its only got a smattering of console fonts, particularly
"usr/share/consolefonts/ter-112n.psf", which I'm not even sure how it works
out.

The only place I have that configured is /etc/conf.d/consolefont and it
somehow works it out.

You may also notice a non-standard 'v86d' in sbin/ , for uvesafb support.

Its added by a simple dracut module I whipped up in 10 minutes, and its far
simpler to do with dracut than it ever was with genkernel.

/usr/share/dracut/modules.d/95v86d/module-setup.sh

#!/bin/bash
# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
# ex: ts=8 sw=4 sts=4 et filetype=sh

check() {
return 0
}

depends() {
return 0
}

install() {
local _d

dracut_install "/sbin/v86d"
}


Been using dracut for 2+ months now and love it.

Sure, I've had to re-implement the bits of genkernel I actually used , and
I still lack an "add it to grub.conf for me" option, but its still overall
a net improvement in my eyes. ( I only ever really used genkernel to
automate compile and initrd creation, all the things that would touch the
.config file I disabled )

Here is basically what I run after I have my .config ready:

https://gist.github.com/1550685


--
Kent

perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 )
for ( 9,8,0,7,1,6,5,4,3,2 );"

On Mon, Jan 02, 2012 at 05:39:39AM +0000, Duncan wrote:
> Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
>
> > On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
> >> I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
> >> deleted.
> >>
> >> However, what I would like to see is that the package maintainers would
> >> be responsible for creating any compatibility symlinks their package
> >> needs, not portage. I don't think it is a good idea to have portage or
> >> any package manager controling the migration.
> >
> > The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
> > then create symlinks from the other dirs to /usr/bin.. That can be done
> > in big move, it's the way Fedora is going to do it.
>
> That's what I had in mind, and in fact have already been thinking about
> trying, here.
>
> Which is why I don't really like the idea of packages placing symlinks,
> since then it'd likely be the symlink copied last, overwriting the actual
> binary with the symlink... pointing at itself due to the symlinked dirs!

If we don't use symlinks at all, we do not have to
force everything in one big move like this, just allow the
package maintainers to update things as new releases come out or do rev
bumps to move their packages. Eventually everything will be off of
/{bin,sbin,lib} and be installed in /usr.

William

On Mon, 2 Jan 2012 07:58:00 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jan 2, 2012 at 6:47 AM, Sven Vermeulen <swift@gentoo.org>
> wrote:
> > And how does dracut know which files it needs to mount my /usr?
>
> I assume based on the selection of modules that you enabled when
> building/running it.
>
> I believe dracut builds static binaries, so it mainly needs updating
> when you build a new kernel.

AFAIK dracut doesn't build anything. It just copies files from
the running system.

--
Best regards,
Michał Górny

On Mon, Jan 02, 2012 at 01:24:00PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Sun, Jan 1, 2012 at 8:59 AM, William Hubbs <williamh@gentoo.org> wrote:
> > Udev, kmod (which is a replacement for module-init-tools which will be needed
> > by >=udev-176), systemd, and soon others, are advocating a major change
> > to the locations where binaries and libraries are stored on linux
> > systems.
>
> Could you please point me to the discussions where udev, kmod and soon
> others are advocating /usr/bin and /bin unification?

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
http://fedoraproject.org/wiki/Features/UsrMove

Also udev git now installs by default in /usr/bin and kmod installs
by default in /usr/bin.

Udev has now also been changed so that it doesn't care if rules fail to
run if/usr is not mounted. It doesn't keep track of this type of failure
and doesn't give us a way to re-run these rules.

That is just the beginning; I'm sure more packages will be changed to
follow this setup.

William

On Sun, 1 Jan 2012 00:16:29 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Sat, 31 Dec 2011 19:59:47 -0600
> William Hubbs <williamh@gentoo.org> wrote:
>
> > Udev, kmod (which is a replacement for module-init-tools which will
> > be needed by >=udev-176), systemd, and soon others, are advocating
> > a major change to the locations where binaries and libraries are
> > stored on linux systems.
> >
> > 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 coulda swore April was another four months away...
>
>

no, in April they will declare the zillions of #!/bin/sh scripts
broken because they rely on a so old unix standard :=)

A.

On Sun, Jan 01, 2012 at 06:54:34PM +0100, Michał Górny wrote:
> On Sat, 31 Dec 2011 19:59:47 -0600
> We should *at least* start doing some preparations, like ensuring that
> random things don't unnecessarily hardcode /sbin or /bin paths. Most
> importantly, if a particular tool runs in a complete environment (which
> is true for most of the cases), there is no need to hardcode paths to
> tools.
>
> As I see it, 2) seems achievable within a reasonable time now. It
> shouldn't require any specific changes from users (except for fixing
> their own broken scripts) yet some tree-wide action of fixing hardcoded
> paths.
>
> We could create /sbin and /usr/sbin symlinks as well but that shouldn't
> be really necessary, especially if we prepare packages well beforehand.
> Introducing such symlinks would be hard to perform and getting rid of
> them later would be even harder; mostly due to PMS-enforced limitations.

I'm not really a fan of the compatibility symlinks either the more I
think about it. I think that basically packages can revbump to make this
migration happen, or in the case of udev and kmod and other upstreams
that support it, not hard code the configuration.

>
> For a long-term view, 1) is the only way to go. Splitting packages
> randomly between rootfs and /usr was never really correct, and we
> especially shouldn't force users to junk their systems with shattered
> packages and cheap glue to keep it all working.
>
> I'd suggest going the other way than I did with kmod. Temporary IUSE
> like 'install-to-usr', disabled by default for now. Packages having
> that IUSE should have correct USE-dependencies, and users who need not
> to use that could just enable 'install-to-usr' globally (we'd probably
> want to mask it first).

I'm not sure that a use flag is a good idea for this, because there will
definitely be people who would turn it off, and with upstreams assuming
that this is how things are installed, those who turn it off will have
broken systems.

Here is My thought about how we can make this transition happen:

* Right now, I can re-work our kmod ebuild to install to its default
locations in /usr.

* When udev 176 is released, I'll put it in the tree, masked, installing
to its default locations. I can actually rework the live ebuild right
now to do this.

* I will then open a tracker for issues that will need to be fixed
before we can unmask it.

* Next, we will need people to unmask udev-176 and test to find issues.
I will definitely be one of these since I have separate
/usr on my desktop, however, I can't test all possible
configurations/packages here, so the more the merrier.

* We also need to get a better understanding of dracut at this point. I
believe that making an initramfs is as simple as running:
dracut "" -H
as root. Then you have to add it to your boot loader. 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.

* Once the issues are ironed out we unmask udev-176 and go from there.

What does everyone think? What am I leaving out?

William

On Mon, 2 Jan 2012 14:54:39 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 1 Jan 2012 00:16:29 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>
> > On Sat, 31 Dec 2011 19:59:47 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> >
> > > Udev, kmod (which is a replacement for module-init-tools which
> > > will be needed by >=udev-176), systemd, and soon others, are
> > > advocating a major change to the locations where binaries and
> > > libraries are stored on linux systems.
> > >
> > > 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 coulda swore April was another four months away...
>
> no, in April they will declare the zillions of #!/bin/sh scripts
> broken because they rely on a so old unix standard :=)

Yes, we should migrate to #!/usr/bin/env sh :P.


--
Best regards,
Michał Górny

On Mon, 2 Jan 2012 11:54:57 -0600
William Hubbs <williamh@gentoo.org> wrote:

> > For a long-term view, 1) is the only way to go. Splitting packages
> > randomly between rootfs and /usr was never really correct, and we
> > especially shouldn't force users to junk their systems with
> > shattered packages and cheap glue to keep it all working.
> >
> > I'd suggest going the other way than I did with kmod. Temporary IUSE
> > like 'install-to-usr', disabled by default for now. Packages having
> > that IUSE should have correct USE-dependencies, and users who need
> > not to use that could just enable 'install-to-usr' globally (we'd
> > probably want to mask it first).
>
> I'm not sure that a use flag is a good idea for this, because there
> will definitely be people who would turn it off, and with upstreams
> assuming that this is how things are installed, those who turn it off
> will have broken systems.

But it will give some of us a chance to carefully test changes without
enforcing them on all users or leaving them to lag behind with
packages.

Another, maybe even better solution is keeping modded packages in an
overlay.

> What does everyone think? What am I leaving out?

I think you are missing the long, necessary transition period.

Also, I don't think we should move udev (or anything else to /usr)
before we move all of its deps there. Well, at least library-level deps
which would be systemd. But I think I'll need to move it there anyway
because we don't have libdbus in rootfs.

--
Best regards,
Michał Górny

On Sun, 1 Jan 2012 14:39:57 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> On Sun, Jan 1, 2012 at 2:23 PM, Sven Vermeulen <swift@gentoo.org>
> 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.
>
> Actually, I've always thought that the split between /usr/bin and /bin
> was quite arbitrary. However, I would like to note that merging /bin
> and /usr/bin would break some app combinations like bzip2+pbzip2, so
> that problem also needs to be solved (via eselect perhaps).

Well, that /usr/bin idea of mine was quite hacky anyway. I don't think
we should even consider it here.

--
Best regards,
Michał Górny

On Sun, 1 Jan 2012 08:53:26 +0000
Sven Vermeulen <swift@gentoo.org> 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.

Simple? Should I start requesting additional packages moved into rootfs
because I feel like needing them? Things can and will go more ugly,
and I wouldn't be surprised if anytime soon people will start
complaining because they ran out of space on their rootfs.

--
Best regards,
Michał Górny

On Mon, Jan 02, 2012 at 07:37:41PM +0100, Michał Górny wrote:
> On Mon, 2 Jan 2012 11:54:57 -0600
> William Hubbs <williamh@gentoo.org> wrote:
>
> > > For a long-term view, 1) is the only way to go. Splitting packages
> > > randomly between rootfs and /usr was never really correct, and we
> > > especially shouldn't force users to junk their systems with
> > > shattered packages and cheap glue to keep it all working.
> > >
> > > I'd suggest going the other way than I did with kmod. Temporary IUSE
> > > like 'install-to-usr', disabled by default for now. Packages having
> > > that IUSE should have correct USE-dependencies, and users who need
> > > not to use that could just enable 'install-to-usr' globally (we'd
> > > probably want to mask it first).
> >
> > I'm not sure that a use flag is a good idea for this, because there
> > will definitely be people who would turn it off, and with upstreams
> > assuming that this is how things are installed, those who turn it off
> > will have broken systems.
>
> But it will give some of us a chance to carefully test changes without
> enforcing them on all users or leaving them to lag behind with
> packages.

Stable or ~arch users wouldn't be affected, just those unmasking things
in p.mask.

> Another, maybe even better solution is keeping modded packages in an
> overlay.

Absolutely not. I don't see a reason to use an overlay for this; that's
what p.mask is for.

> > What does everyone think? What am I leaving out?
>
> I think you are missing the long, necessary transition period.

I'm not sure I agree. I don't see why there has to be a long transition
period if we coordinate everything correctly.

William

On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote

> I see three options:
>
> 1) Start migrating packages along with upstream and have everyone who
> has a separate /usr (including me by the way) start using an initramfs
> of some kind, either dracut or one that we generate specifically for
> gentoo. The reason I suggest the initramfs, is, unfortunately if we
> migrate everything, nothing else would work.
>
> 2) Combine the sbin and bin directories both on the root
> filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin
> to /usr/bin.
>
> 3) Try to maintain things the way they are as long as possible.

4) Following pointers from Zac Medico and others, I've managed to get
Gentoo running with busybox's mdev, instead of udev. See
http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml
Executive summary... look Ma; no udev!

In the instructions there, I've set up a revised dev-manager ebuild in
an overlay. I've requested the changes to be incorporated into the
official ebuild and it appears to have been accepted. See...

https://bugs.gentoo.org/show_bug.cgi?id=395319

It should be rolled out eventually, and the overlay won't be necessary.

I think I've found one item so far that requires udev. My laptop's
graphics chip needs a binary blob from radeon-ucode. That binary blob,
in turn, requires the presence of /usr/lib/libudev.so.0 which is a
symlink to /usr/lib/libudev.so.0.9.3 (which is also required). I can
emerge udev
move or copy the 2 files over to /root
unmerge udev
move or copy the 2 files from /root to /usr/lib/
Note that /usr/lib/ is a symlink to /usr/lib64 on my 64-bit gentoo

> Please discuss; I want to hear what you think.

--
Walter Dnes <waltdnes@waltdnes.org>

Hi Walter,

On Tue, Jan 03, 2012 at 04:51:57AM -0500, Walter Dnes wrote:
> 4) Following pointers from Zac Medico and others, I've managed to get
> Gentoo running with busybox's mdev, instead of udev. See
> http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml
> Executive summary... look Ma; no udev!

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.

William

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?


>
>> 3) Try to maintain things the way they are as long as possible.
>
> I'm all for this one.

I second this too. IMO, unless the FSSTND matches the new proposal from
udev/systemd/etc upstreams, then I think we should stick with what the
LFH describes. It may be possible, too, on this basis, to file bugs
against the upstreams to enforce compatible behaviour??

Of course, 'as long as possible' may depend a bit on what the timelines
are.. I would hope that we can support existing behaviour for at least
the next 6+ months? (at least then, if the Mayan calendar's right, the
end of the world will keep us from having to implement the change)..

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 know that the genkernel initramfs more or less does this (except that
it only attempts to mount 'root' instead of /usr, iirc), but it wouldn't
be hard to implement this behaviour in the main system either.. In
fact, it would probably be possible to emerge a small package that would
do this very thing (although getting behind a udev-controlled /dev might
be tricky at emerge-time -- it would need to have a rather heavy
pkg-postinst).