1 |
On Sun, Jan 01, 2012 at 06:54:34PM +0100, Michał Górny wrote: |
2 |
> On Sat, 31 Dec 2011 19:59:47 -0600 |
3 |
> We should *at least* start doing some preparations, like ensuring that |
4 |
> random things don't unnecessarily hardcode /sbin or /bin paths. Most |
5 |
> importantly, if a particular tool runs in a complete environment (which |
6 |
> is true for most of the cases), there is no need to hardcode paths to |
7 |
> tools. |
8 |
> |
9 |
> As I see it, 2) seems achievable within a reasonable time now. It |
10 |
> shouldn't require any specific changes from users (except for fixing |
11 |
> their own broken scripts) yet some tree-wide action of fixing hardcoded |
12 |
> paths. |
13 |
> |
14 |
> We could create /sbin and /usr/sbin symlinks as well but that shouldn't |
15 |
> be really necessary, especially if we prepare packages well beforehand. |
16 |
> Introducing such symlinks would be hard to perform and getting rid of |
17 |
> them later would be even harder; mostly due to PMS-enforced limitations. |
18 |
|
19 |
I'm not really a fan of the compatibility symlinks either the more I |
20 |
think about it. I think that basically packages can revbump to make this |
21 |
migration happen, or in the case of udev and kmod and other upstreams |
22 |
that support it, not hard code the configuration. |
23 |
|
24 |
> |
25 |
> For a long-term view, 1) is the only way to go. Splitting packages |
26 |
> randomly between rootfs and /usr was never really correct, and we |
27 |
> especially shouldn't force users to junk their systems with shattered |
28 |
> packages and cheap glue to keep it all working. |
29 |
> |
30 |
> I'd suggest going the other way than I did with kmod. Temporary IUSE |
31 |
> like 'install-to-usr', disabled by default for now. Packages having |
32 |
> that IUSE should have correct USE-dependencies, and users who need not |
33 |
> to use that could just enable 'install-to-usr' globally (we'd probably |
34 |
> want to mask it first). |
35 |
|
36 |
I'm not sure that a use flag is a good idea for this, because there will |
37 |
definitely be people who would turn it off, and with upstreams assuming |
38 |
that this is how things are installed, those who turn it off will have |
39 |
broken systems. |
40 |
|
41 |
Here is My thought about how we can make this transition happen: |
42 |
|
43 |
* Right now, I can re-work our kmod ebuild to install to its default |
44 |
locations in /usr. |
45 |
|
46 |
* When udev 176 is released, I'll put it in the tree, masked, installing |
47 |
to its default locations. I can actually rework the live ebuild right |
48 |
now to do this. |
49 |
|
50 |
* I will then open a tracker for issues that will need to be fixed |
51 |
before we can unmask it. |
52 |
|
53 |
* Next, we will need people to unmask udev-176 and test to find issues. |
54 |
I will definitely be one of these since I have separate |
55 |
/usr on my desktop, however, I can't test all possible |
56 |
configurations/packages here, so the more the merrier. |
57 |
|
58 |
* We also need to get a better understanding of dracut at this point. I |
59 |
believe that making an initramfs is as simple as running: |
60 |
dracut "" -H |
61 |
as root. Then you have to add it to your boot loader. The one thing I |
62 |
haven't figured out yet is whether it is possible to create an |
63 |
initramfs that doesn't have to be updated with every kernel upgrade. |
64 |
|
65 |
* Once the issues are ironed out we unmask udev-176 and go from there. |
66 |
|
67 |
What does everyone think? What am I leaving out? |
68 |
|
69 |
William |