On Tue, Oct 13, 2009 at 02:04:56PM +0000, Sylvain Le Gall wrote:
> > At present, I can't find any single case in which using the new
> > mechanism open the flank to more risks than the old one. (Sure, I'm
> I agree on this point, nothing to say more about this. The new system is
> to my mind quite safe (at least I don't see obvious reason that it can
> fail).
OK.
> However, my last point remain: making the package look like any other
> debian package when possible. This is the rule of the "least
> modification", so that we don't use too much special ways of handling
> deps.
I'm sensible to this, and I agree. I'm not entirely convinced that
=${binary:Version} entries are conceptually easier to understand that
${ocaml:Depend} / ${ocaml:Provides} but they are undeniably more
frequent. Also the "leaf package" argument is a very convincing one.
... so, Toots, add back those ${binary:Version} fields :-P
> > [1] Actually, this is rather interesting. I'm surprised that upstream
> > has never thought about this: it would be terribly useful to store
> > in some part of the .so a checksum which is verified at runtime
> > before loading the .so. I guess there is a technical reason for not
> > having done that, but I can't find exactly which at the moment.
> Maybe, the most simple example is a non-custom bytecode binary
> executable ?
>
> Let's choose headache as an example.
I think you're cheating with this example, because a change in the OCaml
compiler can pretty much change everything, and that's exactly why (also
*before* dh_ocaml) we were keeping versioned dependencies on the ABI of
OCaml itself.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature