Bug#98291: being truthful about the FHS and us
On Wed, May 23, 2001 at 12:12:30PM -0700, Chris Waters wrote:
> 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 great and all, but it doesn't say where they *should* go.
At one point, it was, aiui, going to say such things should go in
/svc/cvs or something similar. But that was controversial and didn't
happen. AIUI. IIRC.
I count not giving a sensible alternative place for something to go as
not saying anything useful.
> Are there more? Yes, there's /usr/lib/menu, which we don't even have
> a migration strategy for,
Uh, that's possibly architecture dependent though: it'll contain different
things on different arches if, eg, you support i386 and sparc and have
acroread.deb installed on all arches it supports (ie, i386 only). Likewise
if you have aethera installed wherever possible and have both alpha
machines as well as sparc and i386 machines sharing a single /usr/share.
So /usr/lib/menu seems entirely compliant to me.
> and there are cross-compilers, whose
> time-honored standard locations have been completely banned by the
> FHS.
Right. But again: the FHS doesn't say anything useful about
cross-compilers.
> Bottom line, I'm not entirely ready to trust the FHS. I do trust us.
Likewise. But I think we're aiming for compliance, with some exceptions.
I don't think there's any point aiming for compatibility anywhere.
I'm completely with you on the "But if we have exceptions then we're not
actually being compliant, just compatible" issue, but I don't think that
matters anywhere.
> 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.
Developers have whatever permission they want to violate our *own* policy
if it's necessary to make the system work or to make upgrades work, IMO.
> 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.
It's talking about compatibility that I don't see the value of, not the
"compliance with exceptions" bit.
In practice, a bug report of the form "FHS says not to do this!" will
either get downgraded to wishlist (in the case where the FHS doesn't
leave any better possibilities [0]), or will get the package removed.
That makes it "Packages must comply with the FHS, except <blah>", as far
as I can tell. Compatibility doesn't come into it, as far as how packages
should behave. Our exceptions just happen to not break compatibility.
Uh. Just to make sure I've said something productive in this mail,
count this as a second if the proposed change matches that formula.
Cheers,
aj
[0] /var/cvs is because you can't make dirs in /var. /var/local/cvs
is bad, because the distro shouldn't touch it. /cvs and /svc/cvs is
bad, because you can't create dirs in /. /usr/**/cvs is bad, because
/usr can be read-only. /home/cvs is bad because "cvs" isn't a user.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Reply to: