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
offered.
--
Joseph Carter <[EMAIL PROTECTED]> 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
pgpBouKISW32F.pgp
Description: PGP signature
