On Thu, 03 Jul 2008, Ian Jackson wrote:
> Here is a summary of the problem:
FWIW, the summary is right according to my understanding.
> * This problem is clearly release critical. I don't think documenting
> a release critical bug of this severity in the release notes is
> acceptable. Furthermore, the proposed workaround is very cumbersome
> due to the necessary installation ordering.
It's clearly release critical but doesn't necessarily happen on all
upgrades. It depends if update-alternatives/dpkg-divert is called
between the liblocale-gettext-perl and perl-base unpack.
> * The Debian Perl maintainer's decision to remove the Perl version
> number from the module path is clearly wrong. Here is what upstream
> have to say, and the Debian Perl maintainer's explanation:
> This explanation is basically that `Debian's dependency system
> means that it will work anyway'. This is
> (a) not a reason to deviate from upstream - at best it is only a
> lack of a reason not to deviate;
> (b) false.
> That it is false can be seen from the fact that a problem like this
> has happened for the last three releases: #158835, #278417,
> and now #479711. (There may be other reports of course.)
The problem AIUI is that perl upstream doesn't guaranty ABI stability for
any major release. It might be that all 5.8.x are ABI compatible but it's
not guaranteed. That's why the dependency system includes the full version
in its virtual package (Provides: perlapi-5.10.0 in perl-base). The binary
package get a dependency on the perl version used for the build. Every new
upstream release of perl-base includes the various perlapi-* that it is
It would be a pain to use versioned directories as all perl modules would
have to be rebuilt for each perl release, even if they are ABI compatible.
Simply adding old directories of compatible in the include path is not
very nice... you'll get modules spread over multiple directories.
In general a package offers no guaranty to be functionnal until it is
successfully configured... so the perl module rely on this assumption.
The problem is that some of the non-core modules are used by part of our
essential infrastructure. Locale::gettext is the most important one.
Any script using this module is potentially broken when called in
some preinst script.
In the case of Dpkg, the scripts have been written with this in mind and
tried to use a construct to fallback to a reasonable default behaviour
(with i18n disabled) but this doesn't work for the reasons explained (lazy
> * Suppressing lazy symbol resolution may work in this case, but it is
> not correct. ABI changes may result in random crashes due to
> different structure sizes and do not necessarily involve missing
> symbols - so the problem may go undetected. If we think that we
> want to fix it in etch->lenny by suppressing lazy symbol resolution,
> we need to:
> (a) check what the actual ABI differences are and that either
> there aren't any others besides missing symbols, or that
> every module will definitely fail to load
> (b) regard this as a workaround and do something sensible next
I leave that to perl maintainers.
> * One of the Perl upstream commenters in #479711 suggests that the
> answer is to use a `pre-inst dependency' which apparently none of
> the submitters have realised is what dpkg already has and calls
> Pre-Depends. However, a Pre-Depends doesn't solve this problem
> because there is no correct order to upgrade the packages:
> regardless of whether you upgrade Perl first, or the modules first,
> something may break.
This is why I suggested to integrate liblocale-gettext-perl in perl-base
itself. This would be the simplest/nicest solution IMO. It would always be
synchronized with the current perl.
Unfortunately, it has not been considered yet. :-(
> * The fundamental problem is that there are currently some Perl
> module packages in lenny which whose dependencies are not violated
> by unpacking them into an etch system, but which will break the
> execution of essential packages.
They are violated!
$ dpkg -s liblocale-gettext-perl | grep Depends
Depends: libc6 (>= 2.7-1)
Pre-Depends: perl-base (>= 5.10.0-9), perlapi-5.10.0
There's no way for this to be satisfied in etch. But
somehow you must break the package temporarily:
- either you unpack perl-base first, and it doesn't provide the
perlapi-5.8.x that the old liblocale-gettext-perl require
- or you unpack liblocale-gettext-perl first, and its perlapi-5.10.0
dependency is not yet satisfied until the new perl-base is
> This definitely cannot be fixed
> without changing at least those Perl module packages (because
> an etch system will be willing to install the broken Perl module
> packages right now, and the only thing currently stopping it doing
> so is that lenny isn't released).
This diagnostic is thus wrong.
> 1. Reinsert the Perl version number in the Perl module packages.
> This is the correct long-term solution but involves at least
> rebuilding about 300 packages.
I'm not really convinced that this is manageable.
> 2. Find out which modules are used in this way by Essential packages.
> Arrange somehow for those modules to fail at `require' when loaded
> with Perl 5.8 from etch. This might involve rebuilding only
> those modules.
This works only if the updated modules are unpacked before the new perl-base.
And this isn't guaranteed.
> 3. Make the lenny Perl 5.10 package _also_ look in the directory with
> 5.10 in the name. Change the module(s) used by Essential packages
> to put their modules in that directory. Make the lenny Perl 5.10
> package suppress RTLD_LAZY always. (Specialisation of the above.)
Same here in principle. Using always RTLD_LAZY would work however but it's
also a work-around that would lead to a general performance loss with perl
(no idea if it's important or not).
> 4. Tell everyone in the release notes that it's hideously broken,
> and give them an error-prone 6-rune recipe for upgrading, which if
> not followed will break their system. This is as requested in
> #489132. This is I think hopeless. What is the point of Debian if
> it can't manage to get an upgrade right ?
Well, I did what I could to make the upgrade painless. The rest is up to
the perl maintainers.
I'd like to note that debconf also has this work-around since even longer:
$ grep -C 2 PERL_DL_NONLAZY /usr/share/debconf/confmodule
# Check to see if a FrontEnd is running.
if [ ! "$DEBIAN_HAS_FRONTEND" ]; then
# Since there is no FrontEnd, this program execs a FrontEnd.
# It will then run a new copy of $0 that can talk to it.
Le best-seller français mis à jour pour Debian Etch :
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org