Re: /usr/doc transition and other things
Anthony Towns <aj@azure.humbug.org.au> writes:
> I'm probably making to grandiose a claim here, but I think this is the
> proper way of handling the difference of opinion between Chris (and kin)
> and Manoj (and kith) about mentioning releases by names and doing things
> all at once and such.
I don't think that the differences between my position and Manoj's are
really the problem. I find Manoj's debating style abrasive, but he's
not entirely unreasonable, and neither am I. I think we could have
hammered out a compromise before long. In fact, I had a few ideas not
unlike what you're proposing here.
The real problem is the people like Santiago, who objected to both
Manoj's proposal and mine on the grounds that we've already made the
FHS into policy, and that all these compromises and transitionary
proposals are undermining that. The idea that we might not have
thought of all the issues when we made that initial decision is
something these people seem unwilling to even consider.
I, in fact, have most of a proposal that would have avoided Manoj's
objections to my last proposal (to wit, mentioning releases by name).
I'm not *sure* Manoj would have gone for it, but I think there's a
decent chance of it. Unfortunately, I can't address Santiago's
objection, because his objection is simply that we don't need a
transition strategy. It's hard to propose a transition strategy that
avoids that objection. :-)
> "Documentation must be accessible from /usr/doc/<package>.
> In order to ease the transition to FHS, packages should
> put documentation in /usr/share/doc/<package>, and install a
> symlink from /usr/doc/<package> -> /usr/share/doc/<package>. Due
> do a dpkg bug, this symlink should not be included in the package
> itself, but created by the maintainer scripts like so:
My proposal would have been very similar, with the substitution of
"may" for "should" in the first line of the second paragraph. And
possibly a comment about "at some point in the future, documentation
will be required to be accessible from /usr/share/doc/<package> for
full FHS compliance."
I still don't like the idea of *mandatory* symlinks. It's a lot of
overhead for packages with close-to-nothing in /usr(/share)?/doc. And
I don't like the idea of requiring three releases of low-maintenance
packages when two would really do. For many packages, especially
packages that are updated frequently, and have lots of interesting
info and examples in /usr(/share)?/doc, yeah, symlinks would be good.
But for something that only gets updated every five years upstream,
and has all its docs in the man page, why bother?
Perhaps I'm biased because most of my packages have little or nothing
of interest in /usr(/share)?/doc, and I rarely look there (unless
forced) even for other people's packages. Quite frankly, I dislike
/usr/doc in the first place, and *hate* packages that force me to look
there. Which may be why an ugly transition doesn't scare me -- it's
only adding a little extra annoyance to something that's already quite
annoying, IMO. Docs should be in man pages, or info files, or in html
registered with doc-base, or in on-line help accessible from the
program itself. Anything else is just a hassle, period.
If we just shoot anyone who puts any important documentation in
/usr(/share)?/doc, the problem will basically be solved. :-)
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: