Re: SCL discussion at yesterday's meeting, easy stuff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux