Re: Bug#477732: libgsl0ldbl must conflict with libgsl0
Hi,
I'm adding debian-devel as I would like input from other DD.
The main question is "Do Debian support partial upgrade between
etch and lenny ? Or are only full upgrade supported ?"
Dirk Eddelbuettel wrote:
> severity 477732 wishlist
> tag 477732 + moreinfo
> thanks
>
> On 24 April 2008 at 23:57, Vincent Danjean wrote:
> | Package: libgsl0ldbl
> | Version: 1.11-1
> | Severity: serious
> | Tags: patch
> | Justification: can make other program buging
> |
> | Hi,
> |
> | I see that you rename the package libgsl0 to libgsl0ldbl due to the
> | "double" transition on some arch.
For new people, this is #430259:
"ldbl128 transition for alpha, powerpc, sparc, s390"
> AFAIK that is common standard and always done on rebuild transitions.
with Conflict+Replace, yes (I remember the pain of a lot of transitions
when we had to put some packages on-hold because others where not yet rebuilt
against new the library and I do not want to remove these others)
With only Replace, no: this break partial upgrades
> | libgsl0ldbl replaces libgsl0 as both provide /usr/lib/libgsl0.so.0 for
> | example.
> | But you also need to conflict.
> | Without the conflict, here is what can happen (it happens to me) :
> |
> | libgsl0 is installed
> | progA is installed and depend on libgsl0 as
> | /usr/bin/progA is linked to libgsl0.so.0
> | It use the old version (compiled before the "double" transition)
>
> Is that a local binary? Everything build by Debian is caught with a
> transition from unstable to testing.
progA can be any rdepend of libgls in etch. Upgrading gsl in testing and/or
unstable does not ensure that other etch packages are upgraded.
> | libgsl0ldbl is installed. It replaces /usr/lib/libgsl0.so.0
> | libgsl0 is not removed
> | progA is not removed nor upgraded
> | /usr/bin/progA then uses the new /usr/lib/libgsl0.so.0 with different
> | object sizes (whereas /usr/lib/libgsl0.so.0 always has the same list of
> | symbols)
> | /usr/bin/progA will probably bug or give wrong results. It is possible
> | that this can be used to create a security problem (similar to buffer
> | overflow) but I'm not skilled enough to be sure.
> |
> | If libgsl0ldbl conflicts with libgsl0, when libgsl0ldbl will be
> | installed, libgsl0 will be removed and progA will be removed or updated
> | (if a new version recompiled against the new libgsl0ldbl library is
> | available)
>
> There was a reason why we didn't do this. I just glanced at the Debian
> Policy document, sections 7.3 and 7.5, but I don't find it.
I would be very pleased to see this part. Because this would means that
Debian does not support partial upgrade between releases.
> On the other hand, the chance was made __last June__ and if it really was
> wrong, I would have heard from someone else about it.
The library transition is only required on alpha, powerpc, sparc, s390 and
I do not have such architecture. This means that on i386 and amd64 (at least),
libgsl0 and libgls0ldbl are fully binary compatible. So there would never be some
problem here. I suspect that most of your users are on these architectures
AND/OR they upgrade their machine in a whole so the problem remains unnoticed.
To exibit a real problem, we need
- an effected architecture (alpha, powerpc, sparc, s390)
- AND a partial upgrade on this architecture of libgsl (or any package depending
of the new version of libgsl)
- AND the use of a program that has not been upgraded depending on libgsl0
I agree that this situation must be rather rare and this problem can remain
unnoticed. But once detected, it must be corrected.
If other DD agree with me on that point (partial upgrade supported), then
it can be good to check before lenny if other similar bugs are not present in
Debian (this would join the effort on conflicting/replacing packages due to
similar files that I saw on debian-devel a few weeks ago)
> I do not see this as a bug. Please give me more concrete
> evidence. Otherwise, I find this rather convincingL
>
> edd@ron:~> apt-cache rdepends libgsl0ldbl | wc -l
> 68
> <libgsl0>
> edd@ron:~>
>
> 68 packages correctly depend on libgsl0ldbl and none on libgsl0. So which
> package is this mythical progA from?
Any etch version of these 68 rdepends. If there were no problem, a rename would
not have been required by Matthias Klose.
> Thanks for interest in GNU gsl and your enthusiam in trying to make it
> better. Unfortunately, I think you picked two topics for which you are on
> the wrong side of the argument, but I *do* appreciate the bugreports.
So I will talk a litle more about #477729/456898 in a few days :-)
But for the report, I'm still sure that I'm on the right side *if Debian wants
to support partial upgrade*. If not, then I agree with you that you can close
this bug (but I would be very surprised and even disappointed (from Debian in
general))
PS: I see that you level the severity from a RC severity to an wishlist. This
means that, as it is, lenny can be released with erroneous path for partial
upgrades from etch...
Best regards,
Vincent
> Dirk
>
> |
> | Best regards,
> | Vincent
> |
> |
> | -- System Information:
> | Debian Release: lenny/sid
> | APT prefers unstable
> | APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> | Architecture: i386 (i686)
> |
> | Kernel: Linux 2.6.25-trunk-686 (SMP w/1 CPU core)
> | Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> | Shell: /bin/sh linked to /bin/bash
> |
> | Versions of packages libgsl0ldbl depends on:
> | ii libc6 2.7-10 GNU C Library: Shared libraries
> |
> | libgsl0ldbl recommends no packages.
> |
> | -- no debconf information
> |
> |
>
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
Reply to: