On Tue, Apr 22, 2003 at 11:45:08PM +0200, Bj?rn Stenberg wrote:
Colin Watson wrote:
The reason why a library's shlibs get changed
is that binaries built against one version of the library can't be
guaranteed to run correctly against older versions.
Because the interface changed or
Colin Watson wrote:
The reason why a library's shlibs get changed
is that binaries built against one version of the library can't be
guaranteed to run correctly against older versions.
Because the interface changed or because the previous version was buggy?
I have always assumed the first
On Tue, 22 Apr 2003, Björn Stenberg wrote:
Colin Watson wrote:
The reason why a library's shlibs get changed
is that binaries built against one version of the library can't be
guaranteed to run correctly against older versions.
Because the interface changed or because the previous
On Tue, Apr 22, 2003 at 11:45:08PM +0200, Bj?rn Stenberg wrote:
Colin Watson wrote:
The reason why a library's shlibs get changed is that binaries built
against one version of the library can't be guaranteed to run
correctly against older versions.
Because the interface changed or
Colin Watson wrote:
forcing other packages to always depend on the latest version of them
No, that's not what shlibdeps do.
Right, it does not force the latest, only the version that is installed on
the machine it runs on. But isn't the effect essentially the same, since most
people/robots
On Wed, Apr 16, 2003 at 12:46:07PM +0200, Bj?rn Stenberg wrote:
Colin Watson wrote:
forcing other packages to always depend on the latest version of them
No, that's not what shlibdeps do.
Right, it does not force the latest, only the version that is installed on
the machine it runs on.
Colin Watson wrote:
No, that's not what shlibdeps do either. See:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps
Lovely, so it's simply the other way around (as Adam Conrad said already).
Thanks.
However, it still means packages get bogus dependencies
On Wed, 16 Apr 2003, Björn Stenberg wrote:
However, it still means packages get bogus dependencies that keep them out
of testing. Even if the package in question was already accepted in stable.
The issue is: Define BOGUS.
Most of the time, the maintainers of the -dev packages know very well
On Wed, Apr 16, 2003 at 02:56:21PM +0200, Bj?rn Stenberg wrote:
Colin Watson wrote:
No, that's not what shlibdeps do either. See:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps
Lovely, so it's simply the other way around (as Adam Conrad said
On Wed, Apr 16, 2003 at 12:46:07PM +0200, Björn Stenberg wrote:
Right, it does not force the latest, only the version that is
installed on the machine it runs on.
Not quite. The shlibs file just declares that a package which includes
a program linking against, say, libfoo.so.0 should
Hi,
Through the shlibdeps system. Probably, the libgcc and libc packages
decided that on ARM they should have those versioned dependencies. The
libcurl2 package needs not do anything by itself to pick them up.
Note that the version shown is simply the current libgcc.so version.
Matthias Urlichs wrote:
Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ...
Note that the version shown is simply the current libgcc.so version.
Current as of when? When the upload was done?
dpkg-shlibdeps has no idea whether an older version would be sufficient,
so it plays safe.
On Tue, Apr 15, 2003 at 10:43:50PM +0200, Bj?rn Stenberg wrote:
Matthias Urlichs wrote:
Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ...
Note that the version shown is simply the current libgcc.so version.
Current as of when? When the upload was done?
Current at package
Björn Stenberg wrote:
Matthias Urlichs wrote:
Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ...
Note that the version shown is simply the current libgcc.so version.
Current as of when? When the upload was done?
Current as of when libgcc1 froze the shlibs, which was recently.
Jim Penny wrote:
Björn Stenberg wrote:
Isn't this a problem? Especially for packages depending on libraries with
long release cycles, such as libgcc1 and libc6.
Not often. Most slow release libraries are strongly backwards
compatible.
That was my point. Since these libs are strongly
On Tue, Apr 15, 2003 at 11:48:04PM +0200, Bj?rn Stenberg wrote:
Jim Penny wrote:
Bj?rn Stenberg wrote:
Isn't this a problem? Especially for packages depending on
libraries with long release cycles, such as libgcc1 and libc6.
Not often. Most slow release libraries are strongly
hi,
i don't really know where that gcc-3.2 is coming from. as you can see
curl doesn't depend on it explicitly.
anyway debian has migrated to gcc 3.2 as default compiler and i build
curl with gcc 3.2 since a couple of releases ago. maybe it is required
someway. i'm CC debian-devel@, maybe some
On Mon, Apr 14, 2003 at 03:56:48PM +0200, Domenico Andreoli wrote:
i don't really know where that gcc-3.2 is coming from. as you can see
curl doesn't depend on it explicitly.
You'll find it does on arm and probably one or two other architectures,
but in particular:
Package: libcurl2
Hi,
On Mon, 14 Apr 2003 13:56:48 +, Domenico Andreoli wrote:
i don't really know where that gcc-3.2 is coming from. as you can see curl
doesn't depend on it explicitly.
If it is built with gcc-3.2 and it needs a symbol from libgcc-3.2, then
the resulting package will depend on gcc-3.2.
I
$ ldd `which curl`
libcurl.so.2 = /usr/lib/libcurl.so.2 (0x27ae1000)
libssl.so.0.9.7 = /usr/lib/i686/cmov/libssl.so.0.9.7 (0x27b06000)
libcrypto.so.0.9.7 = /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x27b35000)
libdl.so.2 = /lib/libdl.so.2 (0x27c25000)
libz.so.1
On Mon, Apr 14, 2003 at 03:56:48PM +0200, Domenico Andreoli wrote:
i don't really know where that gcc-3.2 is coming from. as you can see
curl doesn't depend on it explicitly.
anyway debian has migrated to gcc 3.2 as default compiler and i build
curl with gcc 3.2 since a couple of releases
Hi,
Domenico Andreoli wrote:
$ ldd `which curl`
[ no libgcc or similar ]
Duh. You're right. I admit to not being able to think of any other good
(i.e. not-a-bug) reason why this dependency should be there, then. Since
one of my packages has the same problem, I'll go and check why
On Mon, Apr 14, 2003 at 05:17:33PM +0200, Matthias Urlichs wrote:
Duh. You're right. I admit to not being able to think of any other good
(i.e. not-a-bug) reason why this dependency should be there, then. Since
one of my packages has the same problem, I'll go and check why
dpkg-shlibdeps
On Mon, Apr 14, 2003 at 03:56:48PM +0200, Domenico Andreoli wrote:
i don't really know where that gcc-3.2 is coming from. as you can see
curl doesn't depend on it explicitly.
libcurl2 and libcurl2-dbg depend on libgcc1 on arm. libgcc1 supplies
certain parts of the C runtime. There isn't really
Hi,
I'll go and check why
dpkg-shlibdeps (what else??) thinks so.
Well, it doesn't. Not on i386 and ppc, anyway. As aj wrote, though,
apparently it does on arm. :-/
--
Matthias Urlichs|noris network AG|http://smurf.noris.de/
--
We learn from history that we learn nothing
Matthias Urlichs writes:
Maybe it's time to force gcc-3.2 into testing..?
No, it should go in after binutils gets into testing.
Anthony Towns wrote:
You'll find it does on arm and probably one or two other architectures,
but in particular:
Package: libcurl2
Architecture: arm
Version: 7.10.4-1
Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ...
Sorry for being a pain, but how are these
On Tue, 15 Apr 2003, Björn Stenberg wrote:
Package: libcurl2
Architecture: arm
Version: 7.10.4-1
Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ...
Sorry for being a pain, but how are these dependencies assigned?
Through the shlibdeps system. Probably, the
28 matches
Mail list logo
