Bug#83669: Shared libraries
On Sat, Jan 27, 2001 at 01:40:48AM +0000, Ian Jackson wrote:
> Ben Collins writes ("Bug#83669: Shared libraries"):
> > On Fri, Jan 26, 2001 at 07:34:08PM +0000, Ian Jackson wrote:
> > >
> > > foo-dev (2.1) /usr/include/foo.h
> > > /usr/lib/libfoo.so (copy of actual library)
> > >
> >
> > Can we say archive, system, mirror and update bloat horror!? DO you
> > realize what this would mean for lib packages like xlibs and libc6?
>
> Could you please be more specific ?
I thought it was pretty obvious, but I'll explain. If the libc-2.2.1 is
1.1 megs, then the -dev package will increase by 1.1 megs if I follow
your plan. Which means people have to download 1.1 megs more to do
upgrades, and the archive will grow by 1.1 megs times the number of
archs (so in this case, abount 10Megs). libc.so.6 is only one library
(there are lots more in the libc6 package, which means the growth due to
just libc6-dev would be closer to 20 megs).
> > I think your setup is completely broken, since it will be linking
> > against one version of the library, yet running against another
> > (remember the runtime in your scenario will now be different than
> > the link time one).
>
> But we *already* support linking against one version and running with
> another. That's the whole point of shared libraries. In particular,
> it will make it possible (not essential, but possible) to build
> binaries against an older version of the library than you currently
> have installed; this will produce binaries which will work both with
> that older library on other systems, and of course (given that ABI's
> are supposedly upward-compatible) with the one you have installed.
Not in the same sense. We support building and linking with the same
library that we run against *at that moment*. If I compile something
right now against libc6, and then run it, I am running against the same
version as I compiled against. Now, if I have libc6_2.1.3-1, and I
upgrade libc6-dev to 2.2.1-1, then I can now compile for libc6 2.2.1-1,
but I cannot execute the binaries, because the symbols I need will not
be in the runtime libc.so.6 library. So I have not tested this binary
can actually run using the library I built it against.
> Have you never had the experience of a system running stable which
> needs just one package from unstable ? You have to install the libc
> from unstable, so you have to install the libc-dev from unstable, so
> you have to install the libfoobar-dev from unstable for nearly every
> foobar, so you have to install the libfoobar from unstable for nearly
> every libfoobar, and suddenly the system isn't running stable any
> more.
So? This makes things consistent, and much easier to track bugs and
problems. Your proposal would make things really difficult to track
bugs "The bug only shows up when I have libfoo1_1.0 and libfoo-dev_0.9
installed". This puts too much load on the maintainer.
> > This is bad, and creates plenty of problems due to the inconsistencies
> > you create. If we encourage maintainers to link against libraries for
> > which they cannot test the runtime, then you are asking for plenty of
> > untested packages ending up in the distribution.
>
> I'm not saying that maintainers should routinely usually have
> different -dev and runtime packages installed. On the contrary, a
> testing system should have the latest versions, which will correspond.
>
> I don't understand what you mean by `link against libraries for which
> they cannot test the runtime'.
Explained above. Just because you don't suggest maintainers do this,
doesn't mean they wont try. They could potentially try compiling for
unstable, even though they still run stable. They wont be able to test
the packages, since their runtime doesn't support that.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: