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

Bug#102199: Next stage in usr/doc -> usr/share/doc transition

Hash: SHA1

On Tuesday 26 June 2001  7:02 am, Joey Hess wrote:
> Anthony Towns wrote:

> Do you mean accessing docs programatically (rare) or by reference in
> man pages and error messages (sorta common)? If the latter, it seems
> a bit late to ask for a thurough audit of all of debian's man pages
> and error messages and so on before the freeze[1].

Indeed.  After woody is released I (or someone else) probably will do 
an audit of all manpages.  For now I think that actually moving all the 
docs to /usr/share/doc and creating the symlinks is enough to hope for 
before woody is released.  By woody+1 I would hope that the whole issue 
can be resolved.

> Even the former has its problems with finding all affected packages
> and fixing what's sure to be a ton of them in any sane timeframe.

Well, if you want to write a script to find them all and it doesn't 
turn out to be too large a number (somewhere under 50 would be 'not too 
large' probably, depending on how fast freeze is approaching.  I think 
I can manage to edit 50 manpages in a week or so) then I will undertake 
to fix them in a 'sane' timeframe (I am not doing very much during my 
days right now until I find a paying job.  I have time).

Could this be made a lintian check easily?  For example lintian is 
happy to check things like if the pointer to the GPL in 
debian/copyright is correct.  Is a lintain lab the right way to go 
about generating a list of affected packages? (I don't really have any 
idea of the internals of lintian, so if this is way off base then 
ignore me)

> It also has the problem of the web server policy still requiring that
> "HTML documents for a package are stored in
> `/usr/share/doc/<package>' but should be accessed via symlinks as
> `/usr/doc/<package>'" (So at the minimum, your policy patch needs to
> deal with that, too.)

Hmm, I thought it did.  I don't think Anthony is suggesting the 
symlinks should not be there.  Removing those symlinks should IMO be 
done post woody (if at all) and don't really come under the scope of 
this amendment.

> > and two, we need to upgrade any existing
> > bugs about usr/doc to serious (note that current policy already
> > lists this as a "must", so this is a change in spirit not letter).
> >
> > The bugs this may affect are (greping for usr.doc or usr.share.doc
> > in the subject):
> That's an awefully broad brush. We have a set of bugs filed on all
> packages with files in /usr/doc. They were filed by Adam Heath on a
> given day with a single subject, and should be easy to pick out and
> promote to serious[2]. There are probably few enough packages that
> put files in /usr/doc or bugger up the symlink by now that it's
> fixable in a sane timeframe.


There is a list there which is generated from the current Contents for 
i386.  It should be far more correct and complete than Anthony's quick 
and dirty list I believe.  (It is the list I am working from at least)

If anyone does decide to fix a few packages in that list then please 
check the BTS first.  Many of them have patches already done and are 
just awaiting the 21 days of inactivity to upload them.

A lot of the packages so far have just required a rebuild to fix (the 
debhelper based ones at least).  Some have very old scripts that are an 
absolute swine to understand and work through.  Pick a few and go for 
it :)

- -- 
Stephen Stafford
GPG public key on request
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


Reply to: