On 03-01-2012 14:01:20 -0600, William Hubbs wrote:
> On Tue, Jan 03, 2012 at 08:12:06PM +0100, Fabian Groffen wrote:
> > > 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.
>
> Yes, coreutils will have to be reworked in that case. I don't know what
> the upstream build system does, but we will have to take a look at it.
Upstream build system has all binaries just installed in $(PREFIX)/bin,
like normal autoconf-based projects.
> I'll have to go through on my system at
> least and find all of the ebuilds that install things in
> /{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
> released; this will list all of the things we need to do to complete the
> migration.
I would suggest not to do this. It's more interesting to know what udev
really requires to be in /usr/bin.
> Basically I have these in my head:
>
> * mask udev-176 in the tree.
> * figure out and document how to make a simple initramfs with dracut.
> * unmask udev 176 making sure to point users with a separate /usr
> partition to how to make an initramfs (I could probably do this with
> ewarns in the ebuild and maybe a news item before we go stable).
> * stabilize a version of dracut.
> * stabilize >=udev-176 and kmod.
> * Now start stabilizing packages with things installed in /usr instead
> of /.
If the system can work with things being in /, why would we have to move
away from that? I don't like my systems breaking, and this is a likely
candidate to do so. E.g. also gcc-config needs changing for this. And
baselayout/openrc. How many locations for functions.sh are there
already in scripts now?
> If you do not have separate /usr, you could just enjoy the ride. All
> of this would be transparent to you. If you do have separate /usr, the
> critical step will be bringing up an initramfs once you upgrade to
> udev-176. Once that is done, you could also just enjoy the ride.
>
> Thoughts?
Let's just first see how the rest of the world reacts to all of this.
We've waited serveral years with baselayout-1 -> openrc/baselayout-2, so
I wouldn't mind doing some waiting here too. It doesn't look like
there's much going to change. I can't imagine bash devs dropping /bin
from bare default PATH (we control the default PATH), neither that glibc
folks drop /lib from the search path (although more likely since it's
more limited to Linux).
Perhaps, even start to experiment with this in an overlay (it's
relatively easy to start, just disable gen_usr_ldscript, fix bash to
pass --prefix=/usr and coreutils not to move bins) and try to see how
hard migration is with zlib moving around (shouldn't be too hard with
ELF, is a downright drama with Mach-O && without portage's
preserve-libs).
But also, starting to experiment to see how easy it is to let things as
they are. udev might consider a world without /bin and /lib, but maybe
what's in there isn't much interesting to it anyway. Most stuff is
installed in /usr for a reason.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
