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

Re: /usr/share/doc (was Re: weekly policy summary)

On Sat, Jul 31, 1999 at 01:07:40PM +1000, Anthony Towns wrote:
> On Fri, Jul 30, 1999 at 07:55:13PM -0700, Joseph Carter wrote:
> > read "mv" as "cp, verify success, rm old, create symlink, and the whole
> > time deal with things like dropped .dhelp files in /usr/doc while the rest
> > of the package has moved to /usr/share/doc already"
> ...which of course means if you *do* have /usr and /usr/share on the same
> partition, you need to have as much free space as /usr/doc takes up, whereas
> with an ordinary mv (rename(3), anyway), you need no such thing.

No, you need as much space as the single biggest /usr/doc/package dir you
have.  There's no way you can do this all at once safely.  Remember we're
using the dpkg database to figure out what packages are installed here.

> And doing it the way mv(1) does means failures halfway through leave
> you with files in /usr/doc/foo and /usr/share/doc/foo, which could be
> hard to deal with correctly.

Yes, as I said doing it right is not trivial.

> > Not trivial.  But if it were trivial we'd have done it already.
> > Fortunately if this script does something like lock the dpkg database
> > while it does this (a good idea since we're reading that) it should be
> > acceptable.
> This probably means such a script shouldn't be run from a postinst
> (where the package database is already locked, but not only that, cached
> by dpkg).

Indeed, it can't be.

> If it's not run as part of the postinst, we're left with the admin manually
> cleaning up after the packaging system, which was what I thought we were
> trying to avoid.

This is an optional thing (that of course would be recommended to people,
but not forced on them...)

> FWIW, I'm really uncomfortable with having dpkg's database modified by
> hand. Looked at, I can deal with, if only because dpkg is so painfully
> slow. Modifying it just seems like a good way to destroy systems in
> horrid and fanciful ways.

I think in this case it is best to wait until the script/program (I'd be
more comfortable if the thing were compiled) written before I agree or
disagree with you.  So far it's the only solution that has a chance in
hell of actually getting implemented.  If it's implemented properly,
great.  But don't kill it off before it ever gets written.

> I'm tempted to object to any such proposal that doesn't have the support
> of Ian Jackson or Klee Dienes or someone equally familiar with dpkg
> internals.

Then provide a better option.  I'm beginning to agree with Manoj here.
I'm seeing a lot of "I will object to this" and not many better solutions

Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
"What does this tell me?  That if Microsoft were the last software
company left in the world, 13% of the US population would be scouring
garage sales & Goodwill for old TRS-80s, CPM machines & Apple ]['s before
they would buy Microsoft. That's not exactly a ringing endorsement."
        -- Seen on Slashdot

Attachment: pgpWP7sA1AuMg.pgp
Description: PGP signature

Reply to: