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

Re: dpkg binary dbase



On Thu, 7 Sep 2000, David Wright wrote:
> Quoting Bruce Sass (bsass@freenet.edmonton.ab.ca):
<...>
> > The result is still human readable and editable with any text editor,
> > if you know the codes.  The "special dpkg editor" would just make life
> > easier for those not wanting to look up or learn any codes.
> 
> This does two things: (1) the file can be handled as a text file,
> and (2) I can read the numbers 111,999 easier than o^C\347 embedded
> in a binary file.
> 
> But while the appearance might be improved, its meaning is totally
> obscured to us humans. (The whole DNS database exists to present us
> with meaningful information instead of strings of numbers.) "999" means
> nothing, whereas "John Hasler" means words of wisdom on PPP.

"totally" is too strong

> But my point is that you can share the information in a text file (by
> posting it, for example). What good is a file full of codes? Am I going
> to bother to fish out a code book so I can help someone fix a problem?

What is the effective difference between telling someone to make sure
the Status field reads, "install ok installed", and telling them to make
sure the second field after the package name reads, "111".  Sure, it is
less transparent, but the end result is the same and it can be placed in
a message for cut'n'pasting.  I don't think a "code book" would be
necessary, a quick reference page perhaps, but not a book.

> I can also browse and search any disparate set of configuration files
> with standard tools like less and grep.

Actually, grepping would be more productive because it would return more
information per line.  e.g., (using a hypothetical encoded text DB)
	$ grep pppconfig /var/lib/dpkg/status
	$ pppconfig:2.0.5:111:90:999:2:5
The trailing "2" and "5" represent "base" and "optional", the rest
should be decipherable from reading this message and doing
"dpkg -s pppconfig".

I suppose awk (a standard tool, eh) would find more use with this
style of DB... hmmm, you could do more, easier, with the standard tools
than you can presently do with the existing DB.


later,

	Bruce







Reply to: