[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Perl symbol problem - release critical (Re: Bug#489132)

On Thu, Jul 03, 2008 at 10:17:47PM +0200, Raphael Hertzog wrote:
> On Thu, 03 Jul 2008, Ian Jackson wrote:

> > * 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.

Sorry to join in this late, I've been on a family vacation.  Although my
name is on the perl package, I'm really a bit out of my depth here.
Help is welcome.

For the record, at least #489132 (Cc'd), #479220, #479711, #488300, and
#479681 (Cc'd) are related.

As far as I understand, in the case of Etch->Lenny upgrades and
Locale::gettext (which is the most pressing issue here):

- apt will always upgrade both liblocale-gettext-perl and perl-base in
  the same go because of their dependencies
- dpkg will always unpack (and configure) perl-base before unpacking
  liblocale-gettext-perl because the latter Pre-Depends on the former

Furthermore, in my test upgrades with apt the new perl-base is unpacked
(and configured) right before liblocale-gettext-perl gets unpacked, so
no maintainer scripts from other packages get run in between. I don't
claim that this behaviour is guaranteed, only that I don't have a recipe
for reproducing the problem in a real upgrade situation.

My tentative assumption is that the breakage only bites when a version of
liblocale-gettext-perl lacking the perl pre-dependency (that's 1.05-2,
1.05-3 and 1.05-3+b1) is involved, or when the upgrade is done by
installing some packages 'manually' with dpkg. I haven't seen any bug
reports to the contrary yet.

One recipe for breaking update-alternatives and dpkg-divert in such a
'manual' way starting from a minimal Etch install is:

# apt-get install liblocale-gettext-perl
# perl -pi -e 's/etch/lenny/' /etc/apt/sources.list
# apt-get update
# apt-get install libc6
# apt-get -d install perl-base
# dpkg -i /var/cache/apt/archives/perl-base_5.10.0-11.1_amd64.deb 

Note that dpkg doesn't refuse to do this: the dependencies of the old
liblocale-gettext-perl package are violated, but they aren't checked
because liblocale-gettext-perl is not being configured.

> 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.

... or a prerm one ("old-prerm upgrade new-version"), and "only" if the
script doesn't set $ENV{PERL_DL_NONLAZY}.

> > * 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
> >         time.
> I leave that to perl maintainers. :)

FWIW, modifying Perl to always disable lazy symbol resolution in "eval"
blocks was explicitly discouraged upstream because it conceivably could
break existing setups using partly broken binary modules. See


> > * 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.
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479681

There's also the suggestion in #489132 to make perl-base Pre-Depend on
dpkg (>= 1.14.20), whose scripts set $ENV{PERL_DL_NONLAZY} to avoid the
breakage.  As far as I can see, this should work too for the immediate
problem, and it would be even simpler. But maybe I'm missing something?

Brendan already acked the liblocale-gettext-perl/perl-base integration
option in #479681, so I'll work on that for now. If somebody thinks it's
not enough for lenny (for example because other Perl module packages
beside liblocale-gettext-perl need attention too), please speak up.
Niko Tyni   ntyni@debian.org

Reply to: