[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#62378: Redundant directory and package name



> >  Think this: Do the docs document the docs? /usr/share/doc/mutt documents
> > mutt, but /usr/share/doc/mutt-doc... documents... what? mutt-doc? Is a
> > nonsensical place for documentation, I think. It only has some sense from a
> > package management perspective, but that's not ok, package manage should be
> > invisible to the end users, and things shoould fall in the most intuitive
> > place...  I M H O. =)
> 
> I tend to agree with you, but it's not completely cut-n-dry:
> 
> 1. Consider the "I want foo-doc w/o foo": Is it ok for foo-doc to create
> /usr/share/doc/foo and put stuff in it?

 Why not? In the other hand, suppose a package includes a manual, and now
these manual has been split in a separate package... is it ok to have this
package moved to a new location? I don't think so... Many packages already
do what I am saying here...

> What about the /usr/doc/foo
> symlink -- is foo-doc going to take care of that? What if I later
> install foo? Who gets to remove the link?

 I don't know, but this kludge is a secondary thing, and should not be
considered when making policy. Any policy will last longer than these
symlinks.

> 2. What about (first example I found) the tetex situation? There isn't
> a tetex package, so where does tetex-doc install its stuff? (The answer
> seems to be under tetex-doc, with a link in each /usr/share/doc/tetex-*/
> directory.)

 That's a hard one... But shouldn't a tetex package exist? Why not? Shouldn't
tetex-base be just tetex?

> At present, it's pretty random. I would like a consistent answer to make
> its way into policy, but there are lots of different cases, and I don't
> think a simple "foo-doc installs stuff into /usr/share/doc/foo" is the
> best answer. One must also consider that some doc package are actually
> (at least partially) info files and man pages. 

 Perhaps we can't find an answer to every question, but at least we could
regulate how the easy cases are handled. It's better to settle with a
partial solution that cover many cases than to live for ever in kaos.. =)

> Part of the problem is that we've conflated package docs (copyright,
> changelog.Debian.gz,etc.) with user docs.

 That's an interesting thought... but I can't imagine anything more
convenient than what we are doing now...



Reply to: