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:
[...]
Agreed.
> 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!
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: