From: Max H. <ma...@qu...> - 2011-10-26 22:42:04
|
Am 26.10.2011 um 18:36 schrieb Alexander Hansen: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I haven't looked at your RuntimeDepends patch yet, but it sounds to me > like something that would be useful. > > Would we support the seemingly bizarre construction of: > > Package: foo > BuildDepends: bar (= 1.2.3-4) > RuntimeDepends: bar (= 1.2.3-4) > > ? Yes > > At first glance this looks like foo Depends: bar (=1.2.3-4). Not just at first glance, this *is* meant to be exactly the same. Well, if it isn't, then this is a bug in my code. > However, > if I understand correctly, my construction means that an update to bar > can be installed without foo complaining. I don't quite understand how you come to the conclusion that a single Depends has a different meaning thatn bdep + rundep ? > > The real-world case where this came into play is maxima (foo) and > clisp/sbcl (bar). It had been impossible to upgrade maxima in place > from source, because one could build sbcl (originally clisp) but _not_ > install it, because the currently-installed maxima forbade changing > the version. I wound up making a maxima-specific sbcl package to get > around this issue. Well, I don't see how this can be overcome except by first removing the old maxima, then updating sbcl, then building and install the new maxima. This is a problem of the package build loop, not of how we specify dependencies. Fink already has logic to temporarily remove build conflicts. You can exploit this to overcome this issue. Simply add this to your package foo: BuildConflicts: foo (<< %v-%r) In practice, you would replace %v-%r by the last version that depended on a different version of bar. At least in a couple example packages I just created for testing, this worked just fine. Cheers, Max |