On 2006-07-24 John Belmonte <[EMAIL PROTECTED]> wrote: > Andreas Metzler wrote: [...] > > 1.2.9-4 still contains debian/shlibs.local with these contents: > > libxslt 1 libxslt1.1 (>= 1.0.20) > > libxml2 2 libxml2 (>= 2.6.12) > > libgnutls 13 libgnutls13 (>= 1.0.0) > > Why?
> > Have you actually tested that libxmlsec1-gnutls linked against current > > sid (libxml2 2.6.26.dfsg-2, libgnutls13 1.4.1-1, libxslt1.1 1.1.17-2) > > actually works with the old versions you specified? Are you willing to > > repeat this testing whenever a new version of these packages is > > uploaded to sid? Why don't you rely on Debian's shlibs system? > The minimum version numbers I call out in shlibs.local, at least for > xslt and xml2, are defined by upstream. If someone can show that xmlsec > doesn't work in those version ranges, that's an upstream bug. Afaiu, these are the _minimal_ versions that upstream says are needed to *build* the package. (This goes into Build-Depends) The author does not (or should) not claim that a binary linked against libxml2 2.6.26.dfsg-2 will run with libxml2 2.6.12. libxml2's ABI might break backwards compatibility, i.e. packages linked against the new version won't work with the old version, while still retaining forward compability. The libxml2 maintainer will know about it and bump shlibs. That is the whole point of the shlibs system. The library-packager is responsible for providing the versioning info. > I don't > think the burden of proof in this case should rest on the packager. > Calling out actual minimum versions can simplify backports. For backports only Build-Depends is interesting, the binary dependencies of the package in sid (and this is the only thing shlibs.local is modifying) are not relevant, as backports are recompiled against stable. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
