> > That's a half true. Many packages install files in the doc directory of the > > package being documented. /usr/share/doc/doc-rfc/ should only have a > > changelog and a README. > > 1. I subtly avoided those by specifying doc-xxxx rather than xxxx-doc :-) > FWIW, I think we ought to come to agreement about the proper behaviour: > right now I don't know *where* to look after installing foo-doc.
Here the solution is clear to me. A package mutt-doc documenting mutt should put its files under /usr/doc/mutt, i.e. where a user will go to find mutt documentation. > 2. There is no "rfc" package for "rfc-doc" to install with. > > (Yes, both of the above points are rather facetious...) > > > Besides, it would be nice to have many rfc packages: doc-rfc-mail, > > doc-rfc-web, all of them puting packages in /usr/share/doc/rfc. And > > there could be symlinkf pointing to the most recent versions of > > standards: /usr/share/doc/rfc/HTTP would point to rfc2616.txt. > > This is a good argument. I think combined with Colin's idea that it be > called /usr/share/doc/RFC (embracing and extending the HOWTO example) I > could be in favor of it, as it avoids the package namespace. Sounds good, I would agree with this Let's save the game here (doom metaphor). Now: What about other kind of specs? Would it be useful to have a /usr/share/doc/specs/RFC? together with a /usr/share/doc/specs/w3 and such? (do we load the saved game? =) )
