Russ Allbery writes ("Re: Directories named after packages"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
>
> > For example, there has been a recent trend for FOO's documentation
> > package FOO-doc to contain /usr/share/doc/FOO-doc/html/index.html (or
> > whatever). I think this is daft. It should be in
> > /usr/share/doc/FOO/html/index.html. That way you can find the
> > documentation for FOO in the filesystem without knowing whether the FOO
> > package happens to have been split into FOO and FOO-doc, or for that
> > matter libFOO8.9-dev, FOO-bin, etc. etc. etc.
>
> See http://bugs.debian.org/106073 and the discussion there. Wording
> proposals very welcome.
OMG it's from 2001 ...
Ben Finney's patch in message 92 from August seems like a very good
start.
It might be better to actually use the word "administrivia" in the
policy manual, or to use some other wording to make it clear exactly
what should be in the actual package's directory. Something like
adminstrivia (ie, files which document the _binary package itself_,
such the documentation package's copyright file, its (perhaps
duplicate copy of) changelogs, and so on) should be in the actual
package's directory
It would also be useful to specify a convention for libfoo*-dev
packages. Typically for many C libraries we have:
libfoo1.0 } co-
libfoo2.0 } installable
libfoo1.0-dev } conflict, contain
libfoo2.0-dev } dev docs for each version
Ideally I think the documentation location shouldn't depend on which
version of the dev library you have installed, which suggests one of
/usr/share/doc/foo
/usr/share/doc/libfoo
/usr/share/doc/libfoo-dev
Of course you mayhave:
libfoo1.0 } co-
libfoo2.0 } installable
libfoo1.0-dev } conflict, with
libfoo2.0-dev } no documentation
libfoo1.0-doc } each one contains
libfoo2.0-doc } dev docs for each version
Then is it better to have coinstallable
/usr/share/doc/foo1.0
/usr/share/doc/foo2.0
or non-coinstallable
/usr/share/doc/foo
?
I think policy should probably recommend which of these to use.
> In this case, upstream has deprecated the git-WOMBAT syntax as I
> understand it, so you're sort of swimming upstream on that one.
However they can't stop us (Debian) continuing to provide it :-).
A separate thing you put on your PATH is fine for me.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19750.2113.807584.96...@chiark.greenend.org.uk
