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

Re: Bug #32888: The old `base' package.

On Tue, Mar 09, 1999 at 08:37:27PM +0100, Santiago Vila wrote:
> On Tue, 9 Mar 1999, Marcus Brinkmann wrote:
> > 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 [...]
> > 
> > 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?
> zeroing /var/lib/dpkg/info/base.list would be certainly dirty, but not
> very riskful, IMHO.

Guess what, this occured to me a minute after sending the mail :)

I agree. Zeroing the list file is okay. Editing the status file is not.
Does anybody have a base.list file? I'd like to have a look at it, if there
is anything more then /dev/ files, so dpkg doesn't leave cruft around when
we have zero'ed the file.

The best wy to zero a file is "cat /dev/null > the_file", because this will
leave permissions, ownership and time stamps okay. (removing and recreating
is worse).

> Enrique suggested to me (and I agree) that if we wanted to do something
> like that, we could probably do it at least until dpkg changes the format
> of its database (will this happen very soon? I think it will not).

Yes, this is probably better. The problem is with conflicts with future dpkg
versions if we do this now :)
> Since "base" is not available anymore, it is unlikely to corrupt dpkg's
> current databases by zeroing a .list of a package which is not being
> upgraded in any way.

Yes (are there more files in base than dev files?)

> Regarding future versions of dpkg, *if* we implemented some type of
> hack in base-files.postinst, we could remove it as soon as dpkg changes
> its format.

But then dpkg must conflict with older versions of base-files, because
Debian distributions can be upgraded incrementally on a per package base (or
something alike has to be done).
> > [...]
> > 
> > Santiago is right. The risk is not outweighing the benefit.
> Mmm, I did not say that (yet), but yes, I almost did :-)

Consider the latter  my interpretation of why you were right :)

> I think the following could be done:



> Considering that we should not fiddle with dpkg's database unless we have
> to fix a very important bug, I think this is probably everything
> we should do.

This is what I meant. Thanks!


`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: