| 1 |
On 4/10/16 7:55 AM, Joshua Kinard wrote: |
| 2 |
> On 04/04/2016 21:19, William Hubbs wrote: |
| 3 |
>> All, |
| 4 |
>> |
| 5 |
>> I thought that since the usr merge is coming up again, and since I lost |
| 6 |
>> track of the message where it was brought up, I would open a |
| 7 |
>> new thread to discuss it. |
| 8 |
|
| 9 |
Why is this coming up? What problem(s) are we trying to solve with the |
| 10 |
usr merge. I'm still not clear on this. |
| 11 |
|
| 12 |
@William can you please answer this? |
| 13 |
|
| 14 |
>> |
| 15 |
>> When it came up before, some were saying that the /usr merge violates |
| 16 |
>> the fhs. I don't remember the specifics of what the claim was at the |
| 17 |
>> time, (I'm sure someone will point it out if it is still a concern). |
| 18 |
>> |
| 19 |
>> I don't think creating usr merged stages would be that difficult. I |
| 20 |
>> think it would just be a matter of creating a new version of baselayout |
| 21 |
>> that puts these symlinks in place: |
| 22 |
|
| 23 |
If you give me a prototype baselayout (or I can write one myself but I'd |
| 24 |
rather see what you have in mind) I could test some catalyst runs and |
| 25 |
see. I could put these on the /experimental for others to look at. |
| 26 |
|
| 27 |
>> |
| 28 |
>> /bin->usr/bin |
| 29 |
>> /lib->usr/lib |
| 30 |
>> /lib32->usr/lib32 |
| 31 |
>> /lib64->usr/lib64 |
| 32 |
>> /sbin->usr/bin |
| 33 |
>> /usr/sbin->bin |
| 34 |
>> |
| 35 |
>> Once that is in place in a new baselayout, I think portage's colission |
| 36 |
>> detection would be able to catch files that had the same names and were |
| 37 |
>> originally in different paths when building the new stages. |
| 38 |
>> |
| 39 |
>> I put some thought also in how to nigrate live systems, and I'm not sure |
| 40 |
>> what the best way to do that is. I wrote a script, which would do it in |
| 41 |
>> theory, but I haven't tested because I only have one system and if |
| 42 |
>> it breaks it the only way back would be to reinstall. |
| 43 |
>> |
| 44 |
>> The script is attached. |
| 45 |
>> |
| 46 |
>> |
| 47 |
>> Thoughts on any of this? |
| 48 |
>> |
| 49 |
>> William |
| 50 |
> |
| 51 |
> I looked at Thunderbird, at my folder labeled "gentoo-dev", and it had "666" |
| 52 |
> unread messages. I should've done the smart thing and closed my mail program. |
| 53 |
> But noooo, I had to look inside the folder. I am now regretting this decision. |
| 54 |
|
| 55 |
Did you round off to the nearest evil? |
| 56 |
|
| 57 |
> |
| 58 |
> *sigh*, I can see the thread has gone clongie 'round the blonger, so all I'll |
| 59 |
> have to say is we should still try to maintain the choice for users. But, in |
| 60 |
> order to evaluate what amount of effort is needed to maintain that choice, we |
| 61 |
> need to know what packages break on such a setup, what the level of effort |
| 62 |
> needed to fix them is, and do those fixes impact the non-split crowd. |
| 63 |
|
| 64 |
I tested and it will affect systems using RBAC. So if we force people |
| 65 |
to migrate, then users of hardened-sources using RBAC will have to |
| 66 |
update their policy file. |
| 67 |
|
| 68 |
To be clear, I'm not against moving forwards with this, but we can't |
| 69 |
these people hanging because hardened-sources+RBAC is one reason people |
| 70 |
in the industry consider gentoo at all. I'm willing to help with |
| 71 |
backwards compat. |
| 72 |
|
| 73 |
> |
| 74 |
> Create like, a table on the Wiki or some kind of metadata property per-package |
| 75 |
> that can contain a boolean or tri-state flag indicating whether it works or |
| 76 |
> doesn't work (or kinda works) on split-usr. Or a tracker on Bugzie. Something. |
| 77 |
|
| 78 |
+1 |
| 79 |
|
| 80 |
> |
| 81 |
> Once we know this, then we can work out what's the minimum system that can be |
| 82 |
> successfully run on split-usr. Then, knowing *that*, we can see if that system |
| 83 |
> can be supported by our @system target or some minimal subset of @world. As |
| 84 |
> new package versions come out of upstream, we update this metadata with changes |
| 85 |
> to the split-usr status, and this then provides a history of the more or less |
| 86 |
> amount of difficulty needed to maintain support for split-usr, and *then*, we |
| 87 |
> can make an objective decision to continue supporting or not supporting the |
| 88 |
> capability. |
| 89 |
> |
| 90 |
> As for me, I am flat out ruling out a full-reinstall of all my systems. I have |
| 91 |
> fixed disk partition layouts on all of them that cannot be re-arranged unless I |
| 92 |
> tar up each filesystem and temporarily move it off, then rebuild the MD-RAID |
| 93 |
> and reformat the filesystems. I am simply not going to do that on my many SGI |
| 94 |
> systems, and whatever facet of upstream, whether it's some core GNU package or |
| 95 |
> RH itself, can go pound sand for all I care. I'll go back to a static /dev and |
| 96 |
> I'll manually mknod any missing devices if I have to. |
| 97 |
|
| 98 |
Not just you, but many sys admins out there in the real world are in |
| 99 |
similar situation. Again we can move forward on this but not without |
| 100 |
backwards compat planning. |
| 101 |
|
| 102 |
> |
| 103 |
> You know it's getting ridiculous when you can maintain a Windows/NTFS partition |
| 104 |
> layout easier than a Linux one. |
| 105 |
> |
| 106 |
|
| 107 |
Has it come to that? |
| 108 |
|
| 109 |
|
| 110 |
-- |
| 111 |
Anthony G. Basile, Ph.D. |
| 112 |
Gentoo Linux Developer [Hardened] |
| 113 |
E-Mail : blueness@g.o |
| 114 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 115 |
GnuPG ID : F52D4BBA |
Archives