Re: File Systems.
On Thu, 16 Mar 2000 tytso@mit.edu wrote:
> Many distributions are using /usr/bin as where they put
> distribution-provided file, true. I haven't seen one where /usr/bin has
> grown to several gigabytes, myself. But in any case, this is outside of
> the scope of the LSB. The LSB is really about what services, libraries,
> etc. are provided by distribution-provided environments which a 3rd
> party software provider can count on so they can provide a binary
> application that will work on any LSB-complaint distribution.
At a low level, the LSB is about what services, libraries, etc must be
provided. At a higher level, the LSB is about creating a framework to be
used by people and organizations creating additional software. To this
end, LSB must seek to reduce or eliminate the pain-in-the-ass factor for
those who don't want to waste resources figuring out what goes where.
Since the actual details have already been beaten to death at the FHS
level they're not worth re-working here. My point is that a useful LSB
spec must clearly spell out the distinctions between requirements and
recommendations, and it must offer recommendations where requirements
offer multiple paths to the same goal.
> As far as where the LSB-complaint application should be installed,
> that's a matter for the FHS, which currently allows both /opt
> installed applications and integrated /usr installed applications.
> It is agnostic on that point. (Which is good, because we've already
> had the religious wars on the fhs list about which is better, and I'd
> rather not get another denial-of-service attack on my mailbox by
> replaying that whole argument!)
It's insufficient -- and a significant dropping of the ball IMO -- to
simply say "you can put your files in any one of these locations" without
offering further guidance. If the FHS provides options, then the LSB needs
to go a step further and provide recommendations, for the benefit of those
looking to follow the spec who have no existing bias and/or don't care.
An example of this is the developer who's porting something to Linux from
another platform, and doesn't want/need to learn any more about Linux than
the minimum necessary. Such a developer neither cares about choices of
file placement, nor wants to spend any effort figuring out which choice is
best in an unfamiliar environment.
It is IMO the LSB's mandate to offer a default/recommended path where
multiple choices are offered, to refine the FHS without reinventing it.
At its highest level, the LSB is about reducing obstacles, and offering
choices without recommendations needlessly maintains obstacles. By giving
suggested defaults while still allowing other options, we avoid the worst
of the religion while still serving the needs of those who neither know
nor care about the underlying jihads.
> Again, we've had this discussion on the fhs-discuss list. There is a
> place for that in FHS 2.0; it's called /opt. However, we currently
> don't presume to dictate to 3rd party application providers whether they
> have to use /opt or not.
Fair enough. My point is, though, that it is still vital for the LSB, in
instances such as this, to suggest rather than dictate.
--
evan leibovitch <evan@starnix.com> starnix inc.
tollfree: 1-87-pro-linux brampton, ontario, canada
http://www.starnix.com professional linux services & products
Reply to: