Re: dpkg -l and other tools do not report all packages?
Wichert Akkerman wrote:
> Previously Erik Steffl wrote:
> > didn't find anything, I can't even think of what to search for (I
> > tried various combinations of dselect, apt-get and some other words...),
> > browsed 2001, found nothing...
> Look for debian-dpkg arhives and search for design should work
> I suspect. Probably about 1 or 2 months back in the discussion
> about description translations.
what I have found does not seem to have any end, no consensus or
whatever, just a neverending discussion... (not very relevant to the
question in my previous post). The only information is your note that
there will be some changes but you don't know anything more at this
point... this seems to be quite general and even though it was in
discussion about description translation I assume it is valid for the
apt/dselect db problem (both using different db of available packages).
some more confusion:
I just did dselect update and here's one of the messages:
Replacing available packages info, using /var/cache/apt/available.
??? isn't apt where apt-get (part of apt) stores its info?
also, even after running both apt-get update and dselect update both
tools (dpkg and apt-cache) show different number of packages, e.g. for
jojda:/home/erik# apt-cache search kernel-source|wc
8 64 496
jojda:/home/erik# dpkg -l kernel-source\*|wc
34 192 2106
I mean, from user viewpoint it's quite a mess. How come, even after
reading manual pages, getting advice from debian-user and debian-devel I
still cannot find a sure way to list the packages that are available
(based on partial package name)? Is it just me or is it not possible
using current tools?
> > IMO it's quite obvious that any high level tool (front-end) should
> > work with the low level tools (back-end, that's where the db of packages
> > and their states belongs).
> Provided the back-end db can store the necessary info, which it can't
> in this case and Jason decided to create a new db instead of
> enhancing the existing one.
considering that we are talking about the heart of debian here it was
beyond wrong. this basically breaks the nice packaging system... one or
two more decisions like this and you have unusable system.
the only way to go with having the packaging system and different
front-ends is having one back-end, that provides all the information
about packages (status of all packages etc.). any front-end that does
not adhere to this policy should not be allowed into debian. isn't it
of course, the way dpkg stores information about packages has to be
changed, but that's another point (as far as I understand that's part of
what you are refering to in the discussion on debian-dpkg).
sorry to rant like this but I was quite dissappointed (I'm sure you
see "pissed off" in between the lines:-) when I realized what's going on
(of course, I still don't understand it completely). Would more people
working on dpkg help? I am not a debian developer but I would be willing
to put some work into lower level of packaging system (dpkg) (design and
implementation) - unless the new version is already on the way...