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
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-05/msg00426.html
> > * 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: