On Sat, Apr 9, 2016 at 12:06 AM, Anthony G. Basile <bluen...@gentoo.org> wrote: > On 4/8/16 11:03 PM, Rich Freeman wrote: >> >> What problems are you anticipating, especially in light of the fact >> that many distros actually do it this way already? > > RBAC policy files for one. You'll probably break every single hardened > gentoo server out there.
I wasn't suggesting that some adjustments to packages wouldn't be needed to accommodate the change. I was talking about the long-term, after any necessary changes are made? > > scripts and programs that assume different executables with the same > name at different points along the path, eg I know a company where > they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh. I get your point, but the actual case you cited wouldn't be affected by a /usr merge. I appreciate that there are cases where something might be affected (though users shouldn't be sticking wrappers in /usr/bin anyway without packaging them). >> >> I don't really have a problem with making it optional or the default. > > if we don't make it optional we're going to cause some serious headaches > for people who are invested in the current status quo. If you want to use a distro where you can heavily invest in the status quo and not expect it to change I think you'd be better off with a distro like RHEL, which targets this niche almost explicitly. But, as I've said, I see no reason not to make it optional. A big part of why we CAN get stuff like this done is that we let people migrate themselves at their own pace. >> >> It can also be left up to the maintainers, and of course somebody >> could even fork baselayout/etc if they wish and virtualize it in >> @system. Most things in Gentoo don't actually require a consensus to >> move forward, especially if they aren't defaults. > > if we deprecate the linker scripts in /usr/lib by stubbing out > gen_usr_ldscript, then its not as simple as "maintainer's choice". Well, I don't hear toolchain asking to retire that function. If it is their desire to stop maintaining it, then somebody else could of course take over for them and preserve a choice. > >> >> In any case, what is the point of this thread? If somebody wants to >> implement a merged /usr what exactly is stopping them from doing so? > > i'm against something that doesn't maintain backwards compat. > Well, we all have the freedom to fork baselayout if it isn't maintained the way we want it to be. Currently, no policy exists that says the baselayout maintainers can't just maintain the package however they want to (other than the general QA practice of announcing/coordinating changes in advance with trackers/etc). I suppose if somebody wants to propose a policy that says otherwise it is their freedom to do so. Personally, I think our users would be better-served by making it a choice. That might be a choice that comes with some pros/cons, just like the choice to use an initramfs, or the choice to run systemd, or any other choice that we trust our users to make. -- Rich
