Re: Directories named after packages

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Russ Allbery writes ("Re: Directories named after packages"):
> Ian Jackson <ijackson@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.