On Thu, Jan 22, 2009 at 12:05:11PM +0100, Joachim Breitner wrote: > * so-name-line handling > Our ABI hash is technically the same as a soname for a C shared library, > right? Actually, no. If you want an analogue, compare the hashes to the number that some C libraries' -dev packages have, which may be the same as the soname, or then not. Unless compiler developers take libraries' ABI compatiblity issues seriously enough to give guarantees about them, then we shouldn't be relying on them either. GCC and the ELF format are mature and have well defined mechanisms for handling binary compatibility. With GHC, we don't have that. Hash checks of ghc --show-iface's output give a necessary condition for knowing when we need to rebuild, but it isn't a sufficient one. Even if we used hashes in packages' names to mark compatibilities between them, we may still be left with cases where we need to rebuild them anyway, despite having them match. Another reason why C libraries use sonames and mark them in package names is because they're shared libraries. C libraries' sonames allow having multiple versions of a shared library reside on a system at the same time. They allow checking for binary compatibility at the time when a program is run. Haskell libraries are only static, currently. Hash values on them wouldn't convey any information about runtime compatibility, because that's not a concern with static libraries. We only have compile-time compatibility to worry about and we don't have any need to have multiple versions of a library installed at the same time. Lastly, we have releases to consider. I may be old fashioned, but I think that the packaging system's primary aim is to facilitate upgrading from one Debian release to another. Anything else is secondary. Putting hash values into dpkg's domain does nothing to help upgrades from one stable to the next. Compare to sonames, which help, by allowing users to restart upgraded programs and services gradually. I don't think that using interfaces' hash values to control rebuilds is a bad idea. What I'd like to use it for is to gather hashes of Haskell packages' ifaces to an external site that would advise what binNMUs are needed to get every library usable, again, when something changes. Once it gets mature enough we can hook it up to buildds (if RMs agree, etc.) and issue those automatically.
Attachment:
signature.asc
Description: Digital signature