On 4/10/16 7:55 AM, Joshua Kinard wrote: > On 04/04/2016 21:19, William Hubbs wrote: >> All, >> >> I thought that since the usr merge is coming up again, and since I lost >> track of the message where it was brought up, I would open a >> new thread to discuss it.
Why is this coming up? What problem(s) are we trying to solve with the usr merge. I'm still not clear on this. @William can you please answer this? >> >> When it came up before, some were saying that the /usr merge violates >> the fhs. I don't remember the specifics of what the claim was at the >> time, (I'm sure someone will point it out if it is still a concern). >> >> I don't think creating usr merged stages would be that difficult. I >> think it would just be a matter of creating a new version of baselayout >> that puts these symlinks in place: If you give me a prototype baselayout (or I can write one myself but I'd rather see what you have in mind) I could test some catalyst runs and see. I could put these on the /experimental for others to look at. >> >> /bin->usr/bin >> /lib->usr/lib >> /lib32->usr/lib32 >> /lib64->usr/lib64 >> /sbin->usr/bin >> /usr/sbin->bin >> >> Once that is in place in a new baselayout, I think portage's colission >> detection would be able to catch files that had the same names and were >> originally in different paths when building the new stages. >> >> I put some thought also in how to nigrate live systems, and I'm not sure >> what the best way to do that is. I wrote a script, which would do it in >> theory, but I haven't tested because I only have one system and if >> it breaks it the only way back would be to reinstall. >> >> The script is attached. >> >> >> Thoughts on any of this? >> >> William > > I looked at Thunderbird, at my folder labeled "gentoo-dev", and it had "666" > unread messages. I should've done the smart thing and closed my mail program. > But noooo, I had to look inside the folder. I am now regretting this > decision. Did you round off to the nearest evil? > > *sigh*, I can see the thread has gone clongie 'round the blonger, so all I'll > have to say is we should still try to maintain the choice for users. But, in > order to evaluate what amount of effort is needed to maintain that choice, we > need to know what packages break on such a setup, what the level of effort > needed to fix them is, and do those fixes impact the non-split crowd. I tested and it will affect systems using RBAC. So if we force people to migrate, then users of hardened-sources using RBAC will have to update their policy file. To be clear, I'm not against moving forwards with this, but we can't these people hanging because hardened-sources+RBAC is one reason people in the industry consider gentoo at all. I'm willing to help with backwards compat. > > Create like, a table on the Wiki or some kind of metadata property per-package > that can contain a boolean or tri-state flag indicating whether it works or > doesn't work (or kinda works) on split-usr. Or a tracker on Bugzie. > Something. +1 > > Once we know this, then we can work out what's the minimum system that can be > successfully run on split-usr. Then, knowing *that*, we can see if that > system > can be supported by our @system target or some minimal subset of @world. As > new package versions come out of upstream, we update this metadata with > changes > to the split-usr status, and this then provides a history of the more or less > amount of difficulty needed to maintain support for split-usr, and *then*, we > can make an objective decision to continue supporting or not supporting the > capability. > > As for me, I am flat out ruling out a full-reinstall of all my systems. I > have > fixed disk partition layouts on all of them that cannot be re-arranged unless > I > tar up each filesystem and temporarily move it off, then rebuild the MD-RAID > and reformat the filesystems. I am simply not going to do that on my many SGI > systems, and whatever facet of upstream, whether it's some core GNU package or > RH itself, can go pound sand for all I care. I'll go back to a static /dev > and > I'll manually mknod any missing devices if I have to. Not just you, but many sys admins out there in the real world are in similar situation. Again we can move forward on this but not without backwards compat planning. > > You know it's getting ridiculous when you can maintain a Windows/NTFS > partition > layout easier than a Linux one. > Has it come to that? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
