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

Re: dpkg binary dbase



On Fri, 8 Sep 2000, David Wright wrote:
> Quoting Bruce Sass (bsass@freenet.edmonton.ab.ca):
> > 
> > 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.
> 
> Quick reply - it's nerdish.

Oh horror of horrors!
Guess what David, even talking about coding and package management
schemes is nerdish.  If you are worried about being mistaken for a nerd 
you are involved in the wrong discussion.  :)

> More considered: It increases the irrelevant knowledge that has to be
> carried in order to fix things quickly and efficiently. A problem may
> no longer be spotted at a glance, except by people who immerse
> themselves in that sort of thing. A new layer of priesthood is added.

It would be irrelevant if it had nothing to do with the system in
question, but since it would be how the DB communicates to the app...
Naw, the existing priesthood would just have something new to become
familiar with.

> > > 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".
> 
> That's the sort of response I might expect from someone not familiar
> with the A/B/C switches in grep. An alternative way of scanning would
> also be less with the -j command.

How many lines are there in a dpkg status DB entry?
How easy is it to handle multiline records in a pipeline?
Can you be assured of the data for a specific field being in the same
place for each entry?

The answers I come up with are: depends on the record, not as easy as a
single line, and NO.

I'm not sure what machinations dpkg goes through to do something like
"dpkg --set-selections ...", but with the above scheme it would be sed
command  -- that is what I meant by `grep being more productive', not
that grep can't display more than one line at a time, just that a more
succinct output would make grepping useful with less effort. 


later,

	Bruce



Reply to: