Re: Possible dpkg database changes (was Re: Undeclared dependencies on menu)
On Mon, 18 May 1998, Jules Bean wrote:
> --On Mon, May 18, 1998 8:25 pm +0200 "Remco Blaakmeer"
> <remco@blaakmeer.student.utwente.nl> wrote:
>
> > On Wed, 13 May 1998, Joey Hess wrote:
> >
> >> Hundreds of packages use menu. The calls to menu are guarded by a test to
> >> see if menu is installed:
> >>
> >> if [ -x /usr/bin/update-menus ]; then
> >> /usr/bin/update-menus
> >> fi
> >>
> >> Anything using such a test does not have to depend on the command inside the
> >> if statement, as it will install just fine without it.
> >
> > But it may not install 'just fine' if the command is in an unconfigured
> > state.
>
> It seems to me that the correct form for this test is
>
> if [ dpkg --configured menu ]
>
> I.e. we need a reentrant dpkg fast enough to perform checks like this. Or,
> possible separate out the reentrant portions into 'dpkg-check'.
>
> This would imply, to me, that we move the available list, and associated
> files into a fast DB format. Which has seemed to be to be sensible for a
> while anyway - dpkg -l takes far too long for my liking..
>
> Or have I just said something really dumb?
Some people have strong opinions against such a database as the main
source for dpkg's information instead of the text files that are used
nowadays. I think that, to meet both parties, some kind of binary cache
file would be a good solution. The text file would still be the
authoritive source for dpkg's data, but if the cache file would be 'newer'
than the text file, dpkg could simply load the cache file instead of
rebuilding the whole database from the text file. A simple 'stat' could be
the best way to test if the database is up-to-date.
I don't think the idea is entirely dumb, but it could be refined somewhat,
IMHO.
Remco
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: