On Tue, Jun 23, 2015 at 09:31:05AM +0200, Jérémy Bobbio wrote: > But, as far as I know, this information is currently not recorded by > dpkg and there is no way to know for sure which `.deb` has been used for > a package currently installed. I have a couple of memories where this > could have been useful outside of the aforementioned use case.
Not exactly a different use case, but higher level package managers have pretty much the same problem while figuring out if the installed v1 is the version v1 available from archive A, archive B or an entirely different one you may or may not want to upgrade away from. You can either ignore this problem and declare v1 a unique identifier or run crazy like apt does and guess based on fields like the dependencies if this is the same version or not, with all the subtil bugs arising from either… The big problem I see is which hash to store. dpkg itself currently supports only MD5, adding more means finding a free implementation of them to embed or add a new (then pseudo-essential) (pre-)dependency. APT has so far opted for public-domain implementations, but you get complains about it being slower than openssl and alike, which in exchange is a can of (license-)worms apt didn't want to open so far. If dpkg is willing to do that on the other hand… Otherwise sticking with MD5 means that we formally require MD5 to be available in repositories (we don't currently, but I guess very few actually go to the trouble of not having it, so that is more a theoretical concern) and that it is harder to get a deb file securely as you can treat the MD5 just as an ID; you need to establish authenticity some other way (= lookup more secure hashes in Packages file, which you have to validate itself and so on, which is hard™ and rules out simply using snapshots.d.o compared to e.g. SHA256). A way to sidestep these problems would be to allow package managers to ask dpkg to store arbitrary additional fields. This would basically promote the (multi-release long) transition period you would have anyway as dpkg can't retroactively calculate the hashes for already installed packages to an eternal "chaos" of never being quiet sure if the fields are available… Best regards David Kalnischkies
signature.asc
Description: Digital signature
