1 |
On 03-01-2012 14:01:20 -0600, William Hubbs wrote: |
2 |
> On Tue, Jan 03, 2012 at 08:12:06PM +0100, Fabian Groffen wrote: |
3 |
> > > I think the best way to do this part of it is going to be to just follow |
4 |
> > > the upstream packages. When they release a new version that installs in |
5 |
> > > /usr, just allow that to happen. Eventually there will be very little in |
6 |
> > > /{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like |
7 |
> > > /bin/sh. |
8 |
> > |
9 |
> > What packages would that be? If you're thinking about coreutils, just |
10 |
> > trim down the ebuild by not moving some of the tools to /bin. Our |
11 |
> > ebuild makes it conform to FHS, not the coreutils buildsystem itself. |
12 |
> |
13 |
> Yes, coreutils will have to be reworked in that case. I don't know what |
14 |
> the upstream build system does, but we will have to take a look at it. |
15 |
|
16 |
Upstream build system has all binaries just installed in $(PREFIX)/bin, |
17 |
like normal autoconf-based projects. |
18 |
|
19 |
> I'll have to go through on my system at |
20 |
> least and find all of the ebuilds that install things in |
21 |
> /{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is |
22 |
> released; this will list all of the things we need to do to complete the |
23 |
> migration. |
24 |
|
25 |
I would suggest not to do this. It's more interesting to know what udev |
26 |
really requires to be in /usr/bin. |
27 |
|
28 |
> Basically I have these in my head: |
29 |
> |
30 |
> * mask udev-176 in the tree. |
31 |
> * figure out and document how to make a simple initramfs with dracut. |
32 |
> * unmask udev 176 making sure to point users with a separate /usr |
33 |
> partition to how to make an initramfs (I could probably do this with |
34 |
> ewarns in the ebuild and maybe a news item before we go stable). |
35 |
> * stabilize a version of dracut. |
36 |
> * stabilize >=udev-176 and kmod. |
37 |
> * Now start stabilizing packages with things installed in /usr instead |
38 |
> of /. |
39 |
|
40 |
If the system can work with things being in /, why would we have to move |
41 |
away from that? I don't like my systems breaking, and this is a likely |
42 |
candidate to do so. E.g. also gcc-config needs changing for this. And |
43 |
baselayout/openrc. How many locations for functions.sh are there |
44 |
already in scripts now? |
45 |
|
46 |
> If you do not have separate /usr, you could just enjoy the ride. All |
47 |
> of this would be transparent to you. If you do have separate /usr, the |
48 |
> critical step will be bringing up an initramfs once you upgrade to |
49 |
> udev-176. Once that is done, you could also just enjoy the ride. |
50 |
> |
51 |
> Thoughts? |
52 |
|
53 |
Let's just first see how the rest of the world reacts to all of this. |
54 |
We've waited serveral years with baselayout-1 -> openrc/baselayout-2, so |
55 |
I wouldn't mind doing some waiting here too. It doesn't look like |
56 |
there's much going to change. I can't imagine bash devs dropping /bin |
57 |
from bare default PATH (we control the default PATH), neither that glibc |
58 |
folks drop /lib from the search path (although more likely since it's |
59 |
more limited to Linux). |
60 |
|
61 |
Perhaps, even start to experiment with this in an overlay (it's |
62 |
relatively easy to start, just disable gen_usr_ldscript, fix bash to |
63 |
pass --prefix=/usr and coreutils not to move bins) and try to see how |
64 |
hard migration is with zlib moving around (shouldn't be too hard with |
65 |
ELF, is a downright drama with Mach-O && without portage's |
66 |
preserve-libs). |
67 |
|
68 |
But also, starting to experiment to see how easy it is to let things as |
69 |
they are. udev might consider a world without /bin and /lib, but maybe |
70 |
what's in there isn't much interesting to it anyway. Most stuff is |
71 |
installed in /usr for a reason. |
72 |
|
73 |
|
74 |
-- |
75 |
Fabian Groffen |
76 |
Gentoo on a different level |