Re: testing, unstable, and dependencies
On Thu, Feb 06, 2003 at 05:22:02PM +0100, guenter geiger <geiger@xdv.org> was heard to say:
> On Thu, 6 Feb 2003, Daniel Burrows wrote:
> > On Thu, Feb 06, 2003 at 04:50:54PM +0100, guenter geiger <geiger@xdv.org> was heard to say:
> > > Why is it important to link against libnpg3 ?
> >
> > I don't have time to answer right now, so I suggest searching for
> > libpng3 (and possibly "debacle" or "fiasco") on debian-devel. I'll
> > answer in more detail later.
>
> Ok, searching, so you can keep your answer general, I rephrase to
> "Why is it important to link against libfoo3 ..." :)
Well, I picked libpng3 because I assumed you were obliquely alluding
to it, and also because it's a good example of the problem with
too-loose build-deps. (the conditional dependencies someone mentioned
might help, but they're a long way from being implemented)
The issue is that the semantics of Unix linking can cause problems in
the case where an application A links against both libpng3 and libbar,
and libbar links against libpng2. There are a couple of reasons for
this: first, with non-versioned symbols, the linker can't tell which
library version is being called by the program, and picks an arbitrary
function of the same name (I think the first function listed in the
binary happens to be the one that's chosen) Secondly, data structures
may have changed between the two versions. Even if each piece of code
calls functions from the version it was linked to, if it passes a
library data structure to a routine that uses the other version of the
library, the result will be anything from incorrect behavior to a
segfault.
For many libraries, none of this is an issue, and in fact I believe
that many libraries which include the soname in the -dev package's name
Anyway, if the build dependencies allow libpng2-dev to be installed
instead of libpng3-dev, it is possible (this has happened in the past
IIRC) for autobuilders to pick up the wrong package and build broken
packages.
> > Bear in mind while reading the above that Build-Dependencies are
> > dependencies for the *Debian package*, not for the software, and that
> > their most important use is for autobuilders.
>
> Ok, this, in turn means that there is no need for making backporting
> easier, even for those packages where it would be possible.
Not really. They're for the Debian package, which means that they
should guarantee that the package is built consistently -- for
instance, many packages Build-Depend on optional libraries. However,
while their most *important* use is for autobuilders, people use them
too, and if they can be accomodated without breaking autobuilders, that
should be done.
Now, aside from that, I'm not sure it's worth taking too much trouble --
most nontrivial packages I've tried to backport needed enormous
dependency chains to be rebuilt (due to new upstream versions of
libraries), and it seemed to me that it was less trouble (and probably
more reliable) to just upgrade the machines to unstable.
Daniel
PS - I might have misremembered something about the libpng2/3 mess, so
I hope other -devel denizens will be gentle if I did ;-)
--
/-------------------- Daniel Burrows <dburrows@debian.org> -------------------\
| "Inconceivable!" |
| -- "The Princess Bride" |
\---- Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Reply to: