On Sat, May 14, 2005 at 08:12:54AM -0500, Dirk Eddelbuettel wrote: > | > | think we'll want to update those if it's not necessary. Likewise, it > | > | doesn't sound like r-cran-rquantlib needs updating. > | > Well yes -- 0.1.11 corresponded to the 0.3.8 we are replacing in testing. So > | > 0.1.12 would make more sense. > | Ok. If they aren't broken, we won't fix them. quantlib-ruby and > I guess I wasn't sufficiently clear. 0.1.11 is _broken_ as it needs QL 0.3.8. > Given that we settled on QL 0.3.9 we do need 0.1.12. See below for a log. Ah. Please fix the missing dependency on quantlib, then, and I'll push it in. > | quantlib-python are known to be broken, because the previous versions FTBFS > | against the new quantlib. The others would be updated only if there's a > | corresponding reason to do so. > There is, it's just that nobody has a critical bug yet. > > library(RQuantLib) > Error in dyn.load(x, as.logical(local), as.logical(now)) : > unable to load shared library '/usr/lib/R/site-library/RQuantLib/libs/RQuantLib.so': > libQuantLib-0.3.8.so: cannot open shared object file: No such file or directory > Error in library(RQuantLib) : .First.lib failed for 'RQuantLib' > > q() > Save workspace image? [y/n/c]: n > *** This shows that 0.1.11 [ the version in testing ] does not work with Quantlib > *** 0.3.9. [ which will be in testing thanks to your help. On Sat, May 14, 2005 at 09:41:20AM -0500, Dirk Eddelbuettel wrote: > On 14 May 2005 at 15:40, Jeroen van Wolffelaar wrote: > | On Sat, May 14, 2005 at 08:12:54AM -0500, Dirk Eddelbuettel wrote: > | > I guess I wasn't sufficiently clear. 0.1.11 is _broken_ as it needs QL 0.3.8. > | > Given that we settled on QL 0.3.9 we do need 0.1.12. See below for a log. > | Why isn't this reflected in the dependencies then? Dependencies are > | there to reflect which versions of packages work together with which > | other package's versions. > That is a fair and valid question. However, in the ten years I have worked > as a maintainer, I have found that you need to strike a balance between what > is achievable technically with our infrastructure, and what makes sense in > practical terms. There can in fact be a difference: e.g. based on my fairly > extensive experience maintaining Octave -- a package that changed frequently > at times and required a rebuild of all external binary packages to reflect > the new version -- I am not convinced that "hard" are a perfect solution. > Too often something gets stuck and I then need to refer to ftpmaster or > release managers for hinting. I find this creates more trouble than it > solves. The hard depends on Octave lead to blocking more often than we liked. > But I welcome the release teams view on this. If you guys all state that I > should really have hard depends, I will change my mind on this. Feedback welcome! Packages absolutely are expected to have dependencies that reflect, to the best of the maintainer's knowledge, the requirements for the use of the package. If it's known in advance that certain ABI changes will break binary compatibility for dependent packages, the dependencies should be structured to prevent packages from being installable but not usable. This is important to ensure both smooth transitions in testing, and successful partial upgrades between stable releases. I would greatly prefer that you come to the release team when something needs to be hinted, rather than letting broken package combinations sneak into testing. This should certainly be an easier case of hinting than most libraries anyway. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature