On Mon, 24 Sep 2001, Joey Hess wrote: > maintains more complex package list information than can be represented > in dpkg's available file (especially if you have apt set to use multiple > distributons at the same time, etc).
Yeap, pretty much. > I find this very unsatisfactory. Yes, generating an available file > whenever apt-get update is run may not be technically perfect, and the Well, here is my rant.. > * tasksel > * grep-available > * dpkg -p > > That should _just work_ in a high-quality Debian system. You notice that all but dpkg -p were written after APT? They were written with full knowledge that that available file would be inaccurate on 99% of their users systems. They could have been written to use apt-cache on systems that are using APT and this would be a non-problem. In fact, as long as APT is involved the only way to have things just work is to call 'apt-cache dumpavail' and parse that. That function accounts for all variables and presents the same selections that apt-get would see. The reason these tools don't do this is some IMHO mis-guided aversion to assuming APT is being used. After all, there are 2 people out there who don't use it.. Similarly checking if the APT is selected in dselect would be inelegent :P The only way I can see to compromise around this is if someone changes dpkg. Yes, the limited interface to it's methods is unsuitable and must be extended. I suggest that someone cook up a patch to dpkg that changes it to effectively popen the script /usr/lib/dpkg/methods/*/get-available and parses that instead of the available file. Dpkg would also need an way to dump the available file to stdout.. Jason