On Mon, 19 Jun 2000, Joey Hess wrote: > > 2) To support other programs that try to directly query the available > > file [bad in the first place], or use 'dpkg --print-avail' > > 3) Because a large number of books, documentation files, and mailing > list posts refer to dpkg --print-avail it, and so it is what a new user > is going to encounter and try to use first. And when it doesn't work ...
That same documentation generally doesn't even mention apt or apt-get, so it is not entirely unreasonable that things change over time. Also, if those docs don't say you need to run [U]pdate to freshen the avail file then then are just plain wrong. I can't help it that someone decided to weld dselect+dpkg together :< If --print-avail was in some non-dpkg binary then I would just dirvert+wrap that binary. Maybe I should lobby wichert to create a lib/methods/available interface, and make dpkg --*avail exec it and also make dselect popen it. This program would have a argument to get the whole available file and an argument to return records with a search string, maybe some other things too. Old dpkg methods would just use a default program that used /var/lib/dpkg/available and APT would provide one that dynamically built information from the version pin table and /var/state/apt/lists. By putting it in the dselect methods dir it neatly fits into the dpkg paradigm and is not APT specific. That would make everyone quite happy, yes? > Well I think a lot of us just thought this was some weird unimplemented > corner of apt. After all, where is the documentation that says apt > was intended to break the available file? Where is the documentation that says anything but dselect methods update the available file? Remember, way long ago apt-get had to co-exist with a non-apt dselect method so doing this update automatically would have been quite bad. Jason
