Bug#98291: being truthful about the FHS and us
On Wed, May 23, 2001 at 09:17:57PM +1000, Anthony Towns wrote:
> (The exceptions we allow are cases where (a) the FHS doesn't really say
> anything useful, like where CVS repositories should go, and (b) /usr/doc,
> which we're aiming for compliance with anyway. Are there more?)
As for (a), the FHS may not say where repositories go, but it *does*
say that "[a]pplications should generally not add directories to the
top level of /var. Such directories should only be added if they have
some system-wide implication, and in consultation with the FHS mailing
list." Which is not unreasonable, but there are other cases where it
explicitly forbids adding more subdirectories to a particular
directory. Those cases may or may not allow for a reasonable upgrade
strategy.
Has anyone consulted the FHS list about /var/cvs?
As for (b), no, we're aiming for compatibility! Grrr! :-)
Are there more? Yes, there's /usr/lib/menu, which we don't even have
a migration strategy for, and there are cross-compilers, whose
time-honored standard locations have been completely banned by the
FHS. And there may be more. The FHS is not road-tested yet.
Once we achieve compatibility (overall, not just with /usr/share/doc),
and release a transitional system, *then* it will be time to start
focusing on compliance. And maybe by that time, our experience will
have informed the FHS, and *it* will be a better document, more suited
to our actual needs.
Bottom line, I'm not entirely ready to trust the FHS. I do trust us.
We might find, say, a dozen edge cases where strict compliance isn't
going to work, especially during a transition. If those edge cases
affect only one package each, it's not worth specifying each one in
policy. Better, I think, to explicitly grant permission in advance to
our developers to do what they need to do to make the system work, and
make upgrades work.
Eventually, just as we're going to change policy about /usr/doc, we're
going to want to change this section. We might even go back to saying
"must comply with FHS" period, someday. But for now, while we're
still in transition, I think it's wisest to allow ourselves some room
for common sense to override untested standards.
I think "or would be impractical or unreasonable" is a very useful
clause to have _at this point_. I'll pull it if everyone really wants,
but I'll be uncomfortable doing so.
cheers
--
Chris Waters | Pneumonoultra- osis is too long
xtifr@debian.org | microscopicsilico- to fit into a single
or xtifr@speakeasy.net | volcaniconi- standalone haiku
Reply to: