Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: Directories named after packages"):>> See http://bugs.debian.org/106073 and the discussion there. Wording >> proposals very welcome. > OMG it's from 2001 ... Yeah, it's almost old enough that I can blame you for the fact that it wasn't specified that way in the first place. :) Not quite, though. > Ben Finney's patch in message 92 from August seems like a very good > start. Agreed. I'm copying the bug on this message to capture your feedback. > 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 I'm not sure -- administrivia is one of those words that is immediately meaningful to me, as a native English speaker, but it's one that sets off warning bells about whether it would make a lot of sense to someone who wasn't a native English speaker and isn't that familiar with English idioms. Of course, you do immediately then define it. But I'd be inclined to just inline that definition in place of the word. > 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. I'm hesitant to recommend moving the documentation to /usr/share/doc/foo when we've always put it in a directory named after the package in the past; I'm afraid long-time Debian users won't be able to find it. I suppose symlinks would solve that problem. In my ideal world, as a green-field proposal, I'd like packages: libfoo1.0-doc libfoo2.0-doc to install their documentation into: /usr/share/doc/libfoo/1.0 /usr/share/doc/libfoo/2.0 I would tend to use libfoo instead of foo unless upstream's name is always foo. For most libraries, libfoo is better because foo may be something else entirely (something that uses the library, for instance). But that's a big difference from what we have now. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o9l7rzg....@windlord.stanford.edu
