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.
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.
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 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?
William
pgpwrpWUR5VAh.pgp
Description: PGP signature
