interpreting Status field in dpkg status/available file

[Craig Sanders <cas@taz.net.au>]

i've finally found some time to start working on dlocate again, and one
of the things i'm doing is fixing the dlocate -l" search feature.

one of the things i need to do is parse the Status field so i can produce
the same 3-letter codes that dpkg does.

so far, i have the following Q&D hack:

($key,$val) = split /: / ;
...
} elsif ($key eq "Status") {
my($a,$b,$c) ;

#Desired=Unknown/Install/Remove/Purge
#| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
#|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)

#Desired=Unknown/Install/Remove/Purge
$a = "u" ; # default to Unknown
$a = "i" if ($val =~ /^install/oi) ;
$a = "r" if ($val =~ /^remove/oi) ;
$a = "p" if ($val =~ /^purge/oi) ;
$a = "h" if ($val =~ /^hold/oi) ;

#| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
$b = "n" if ($val =~ / not-installed$/oi) ;
$b = "i" if ($val =~ / installed$/oi) ;
$b = "c" if ($val =~ / config-files$/oi) ;
$b = "u" if ($val =~ / unpacked$/oi) ;
$b = "f" if ($val =~ / failed-config$/oi) ;
$b = "h" if ($val =~ / half-installed$/oi) ;

#|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
$c = " " ;
$c = "h" if ($val =~ / hold /oi) ;
$c = "r" if ($val =~ / reinst-required /oi) ;
$c = "x" if ($val =~ / hold /oi && $val =~ / reinst-required /oi) ;
$c =~ tr/a-z/A-Z/ if ($val =~ / not-ok /) ;

$status{$package} = $a . $b . $c ;

} 

$a and $b are, AFAIK, correct. $c is almost completely wrong, i just
made it up. the routine produces correct codes for packages without any
errors, but incorrect codes for error conditions.

as written, the search script actually works and is useful for most
purposes...but i want it to be perfectly correct.

i could trawl through the dpkg source code to find out...but
implementing from documentation or a spec would be faster and better.

anyone know if this is documented anywhere?  

craig

ps: btw, i'm still planning to pre-generate a searchable package
listing in a nightly cron job - on my dual p3-450 with 256MB, a perl
grep operation on that "cache" file takes about 0.075 seconds per
search, whereas searching the real status file directly takes about
3 seconds....that's about 40 times slower per search on a reasonably
high-end system with plenty of memory, it would be much worse on a
system without enough memory.

the disadvantage here is the same as with the previous "dlocate -l",
it won't always be up-to-date. i actually find that useful because it
lets me compare what packages were installed yesterday versus what
packages are installed right now. in any case, a user can always run
"/usr/sbin/update-dlocatedb" manually if they need it updated.

pps: yes, i'll be going through the dlocate bug reports and fixing the
reported bugs (including the often-reported slocate renaming locate bug)


--
craig sanders <cas@taz.net.au>

      GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0