Hi, Raphael Hertzog wrote:
> 1/ It concerns packages which have not been touched since 2004 or packages > which were installed before 2004 and got removed but not purged since then I did say "ideally". I can understand if you're not motivated to work on it. (That said, iiuc the above is not so rare of a usage pattern. Some people never purge packages until they have to, to save some trouble reconfiguring when it is time to install again later.) > 2/ We can't invent the value to put in Architecture It seems likely this has been covered before, but just in case: why not put in the native architecture for already-installed, ancient packages? If I am reading the multiarch spec correctly, i386 packages cannot satisfy dependencies from amd64 packages without a "Multiarch" field, and i386 packages are not co-installable with other packages of the same name without a "Multiarch" field. So although this would be technically inaccurate (some of the ancient packages were presumably Architecture: all), I think it should be safe. > dselect update sometimes does depending on the "method" configured. > > Right now, it serves no purpose for apt-get to update the available file. Actually I'm a bit puzzled by the behavior. sync-available (from dctrl-tools) and the apt method's "update" script call "apt-cache dumpavail" to write a new available file and "dpkg --update-avail" to use it, ignoring the old one. So why are people needing to run "dpkg --clear-avail"? Would it be possible in the long term for dpkg to stop caring about "available" altogether (leaving it to dselect)? >> Especially for the sake of cross-upgrade support, the architecture >> field seems kind of important. > > Which is why we're requiring it now and why we're more verbose. Yes, and thanks for that. Without a warning to point out these old package records, it would be a lot harder to figure out what to do about them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org