On 12-10-2009, Stefano Zacchiroli <[email protected]> wrote: > On Mon, Oct 12, 2009 at 09:13:50AM +0000, Sylvain Le Gall wrote: >> It is almost the same thing, but I think it is more clear with a (=3D >> ${binary:Version}).=20 >>=20 >> The main difference, is that in the case of dev -> runtime dependency >> we can have stronger dependency. As you know, there is a probability to >> miss some depends due to the hash/limitation in precision. For this >> deps, we have enough information to set a stronger dependency.=20 > > OK, so in fact the (=3D ${binary:Version}) *is* subsumed by the new > dependency scheme, but it suffers of the usual limitation of > checksums. I don't see keeping (=3D ${binary:Version}) as the obviously > right solution. For instance, it has the drawback of forcing > reinstallation even when the ABI (according to checksum) has not > changed. >
I think it is a bit dangerous to have libX-ocaml v1.2 fullfill the dependencies of libX-ocaml-dev v1.3 if there is nothing detectable in the ABI checksum. Moreover, you must also take into account that we will not have 1 but 2 dependencies foreach native package (libX-ocaml-dev-byte-WWWW and libX-ocaml-dev-YYYY). We must separate byte and native dependencies. This will also add 2 dependencies for intra-dependencies. With binary:Version we just get 1 deps (+ version). I must also admit that even if I found the system well working, I prefer to keep things as much as possible look likes old/other Debian packages. The -XXXX digest extension is to my mind only allowed by exception, if we can avoid using it, we should (but this is Zack that has negociated this, so I don't know the real extent of the exception). Call me conservative ;-) Regards, Sylvain Le Gall -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
