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

Re: Packages with documentation only in /usr/share/doc

On Sun, Feb 06, 2000 at 01:58:08AM +0000, Julian Gilbey was heard to say:
> On Sat, Feb 05, 2000 at 04:49:56PM -0500, Daniel Burrows wrote:
> > It's fairly
> > simple to write a script that at least tries to find packages that do this:
> > 
> > for i in /usr/share/doc/*; do
> >   if [ -d $i ] && ! [ -l /usr/doc/`basename $i` ]; then echo $i
> >   else; if [ -l $i && ! [ -l /usr/doc/`basename $i`]; then echo $i; fi; fi
> > done
> One other thing: it's not at all obvious to test for packages which
> don't manage to clean out the old /usr/doc directory when moving over
> to the new one, except by using bug reports :-(

  Yeah, I agree that there isn't a perfect solution here, but the script was
meant to do exactly what you said: find packages whose preinst/postrm scripts
don't create the link in /usr/doc or leave cruft there.  I'd like to file
bug reports against all packages that turn up this way, but I'm not sure
(a) what severity level is important -- should it be release-critical that a
 package's documentation is in a non-standard location (I agree with Ben that
 moving everything to /usr/share is a nice idea, but it doesn't look like
 that'll happen in potato, and one place to go for docs is a really good idea)
(b) What should be done about transient problems?  For example,
 /usr/doc/xfree86-common is cruft on my system.  On the other hand, the
 ChangeLog claims that this problem is fixed.  So the only people affected by it
 are people who were tracking potato when the problem occured.  Is it worth it
 to file a bug saying that xfree86-common should clean up this one case, or
 should I just rm the tree myself?
  Anyway, here's a list of 'problematic' directories on my system, generated
automagically as above:



All generalizations are dangerous.

Reply to: