On Thu, Nov 7, 2013 at 6:34 AM, Honza Horak <hhorak@xxxxxxxxxx> wrote: > > > That makes sense, I had to miss that point, thanks. Altough I'm still not > persuaded /usr is somehow better than current /opt from technical > perspective (keeping aside FHS POV for now) -- I don't remember any > technical reason from couple of discussions here and there; the only problem > with /opt is based on some uncertainty if /opt was designed for such purpose > in FHS or not, right? If not, could someone sum up the main pros and cons of > /opt (again, aside FHS perspective)? > > My point is that since FHS has been labeled like obsolete not only once > already, shouldn't we focus more on the technical details and if there are > no differences, just prefer the current design for compatibility reasons? > FHS is kinda a tangent but it's worth talking about: The FHS is not obsolete in the sense that when your car is obsolete you buy a new car and throw the old one out. It could use expansion and in one or two places a clarification but it still serves as a common understanding of what concerns affect the various major hierarchies of the filesystem and serves as a starting point for organizing the files to be placed on them. No one is going to throw out FHS and start over from scratch (if you want to do that, see gobo linux :-). However, there are two routes that can be taken: 1) Try to fit in with an existing FHS specified hierarchy. Ironically, that's what a proposal to put it in /opt is. /opt is designated by FHS as a place for vendors and local system admins to install code. If we want to install scls there we have to play by the expectations the FHS establishes for its use. Because multiple parties install code here, the FHS has to have rules about where code can be installed to avoid one set of software overwriting software installed by someone else. Those of us who see /opt as an okay place to put (some of the files from) an scl think that we can specify a vendor directory and place them in there. Something like /opt/fdr/scls/scl-foo1.0/. However, others argue that we're late to the party. Since this is an area that the sysadmin is allowed to install into, the sysadmin may already have used the vendor string that we choose to install something else (that's why I use "fdr" instead of "fedora" in the above example... the chances of a collision with "fedora" seem even higher). We would then be overwriting their installed software which is not allowed. 2) Expand the system to include a new hierarchy for what we want to do. The advocates of using /usr/scls are essentially saying that the FHS doesn't provide a good place for scls to reside. We need to create a new hierarchy for them. That hierarchy/mountpoint happens to reside under /usr/. -Toshio -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
