On 4/8/16 11:03 PM, Rich Freeman wrote: > On Fri, Apr 8, 2016 at 9:51 PM, Anthony G. Basile <bluen...@gentoo.org> wrote: >> >> Alternatively, this may introduce problems. So it seems like we're >> fixing something that isn't broken. >> > > 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. 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. security measures where you don't dereference sym links along $PATH because sym links can be used in various types of exploits. really, it doesn't take much imagination to come up with scenarios where you'll break people systems. > > 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. > > 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". > > 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. -- 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
