[please direct followups appropriately, this digression doesn't really belong on -policy]
On Sun, May 31, 1998 at 09:26:38PM -0700, Karl M. Hegbloom wrote:
> >>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
> Anthony> (as it stands, things like `dpkg --search /etc/passwd'
> Anthony> results in `dpkg: /etc/passwd not found.' Personally I
> Anthony> consider this alone a little disconcerting)
> ... and it takes forever and a day of disk ggzztting to give you the
> result too. I will be glad when the contents of some future and
> quick database have been worked out, and that database gets built.
> `dpkg' could be as fast as `rpm' then.
I'm personally against moving towards a heavily optimised databasey
format, for the simple reason that I like being able to get at stuff
with less and grep.
There are a couple of things which might be worth considering though.
In particular, I suspect pre-sorting [0] all the .list and .conffiles,
and using a binary-search for dpkg --search (and probably a different
data structure when doing other operations (a binary tree, built to be
balanced, with additions as necessary, perhaps?)) would go a fair way to
tidying it up. I suspect splitting dpkg/info into subdirectories would
do some good to.
Has anything along these lines already been done in the experimental
dpkg, btw?
Cheers,
aj
[0] Either by having a flag on the dpkg/info database that indicates
whether it's sorted [a version number?], or by doing it "manually"
in the pre/postinst, or some other way. I have no idea of the
complexities involved in using dpkg to upgrade itself in an only
semi-backwards compatable way.
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``It's not a vision, or a fear. It's just a thought.''
pgpYxTWKcjtGb.pgp
Description: PGP signature
