On Sat, Apr 09, 2016 at 12:06:47AM -0400, Anthony G. Basile wrote: > 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. Tell me more about this; I don't know a lot about what would break. Also, are you sure it would break, or are you just thinking that it would?
> 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. This won't break, because /usr/bin/ssh would still exist as it does and /usr/local is not touched. File colissions between the directories that are being merged would definitely be an issue that needs to be worked out before this could happen, and I understand that. I know of at least one, and we would need to find out if there are others. Forgetting about /usr/local since we don't control that, this type of file name collision across the bin directories is not good whether or not you merge /usr. It would cause issues in path name resolution. > security measures where you don't dereference sym links along $PATH > because sym links can be used in various types of exploits. Every amd64 gentoo system already has one of these, the "lib" symlink, both in / and /usr, so if you aren't dereferencing symlinks, aren't you already broken? > > > > 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". gen_usr_ldscript is only needed if you are using separate /usr without an initramfs. This is unsupported and orthogonal to the usr merge. > > > > 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. If there are ways that merging / into /usr does not maintain backward compatibility, I want to know what they are. This is not directed at anyone specifically, it is just a general comment. I've seen a lot of speculation on this thread about what might break, and a lot of comments about a perceived removal of choice. Can someone help get a summary together? let's get a single message summarizing everything. Thanks, William
signature.asc
Description: Digital signature
