Re: Bug #32888: The old `base' package.
On Tue, Mar 09, 1999 at 12:42:42PM -0500, Jonathan P Tomer wrote:
> This can be done by making
> the post-inst of either base-files or base-passwd, or something on which
> they both depend (but the old base did not), hack dpkg's database to
> remove /dev/* or whatever from base's file list (without actually removing
> the files, of course... that's what we're trying to prevent), so that base
> could safely be removed. in order to be sure this happens -before- base
> is removed (though dselect and apt will use the right order normally it
> could be done differently, and this is bad) we could make a new package
> base that pre-depends: base-file-list-hack, which would make a safely
> removable empty package that could be obsoleted in the next release (safe
> unless someone upgrades two releases at once, skipping potato).
So you want to enforce a dirty and _riskful_ operation, which even might be
incompatible with future dpkg releases to get rid of a few bytes who don't
harm anyone?
Please go ahead and write a safe routine which does this, debug it and test
it on a few systems. Then file the patches to the BTS. But be sure that it
does not corrupt dpkg's database when the maschine crashes, and that it does
not corrupt databases of possible future versions of dpkg and whatever.
> i know it's not an -elegant- solution, but it is imho better than having
> a useless (yes, it -is- useless for releases that don't have it in their
> archives) package around.
Slow down and come back to earth again, will you? What harm does the base
package do? Are you such an aesthet that you can't stand the look of an
obsolete package in dselect? Or are you short of disk space and you need the
4096 bytes of the list file of base package?
Messing with dpkg's database is not funny, and I would consider such a
procedure harmful. A package is not allowed to mess with the files of
another package (usually). dpkg's database format is not guaranteed.
> but then again, i thought the same thing about
> the great x reorganization (though the reason the font packages weren't
> subjected to this solution was iirc because they -didn't- hose a system)
> so maybe the response to this is predictable :)
Santiago is right. The risk is not outweighing the benefit.
> comments appreciated; flames cheerfully ignored so go ahead but in
> private mail please.
You ignore your own email? Interesting.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: