| 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 |
Archives