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

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


On Thu, 2008-08-21 at 00:52:44 +0300, Niko Tyni wrote:
> The only perl scripts provided by Essential packages are
> /usr/bin/scriptreplay

This one comes from bsdutils, and it's fairly short (around 30 lines
with comments).

> /usr/bin/chkdupexe

And this one is a bit longer, but still short (around 120 lines).

> /usr/sbin/cleanup-info

Going to disappear.

> /usr/sbin/install-info

Should be split into its own package and moved out of essential,
post-leny. The version from GNU that's going to replace the dpkg
version is in C already.

> /usr/lib/dpkg/mksplit
> /usr/sbin/update-alternatives
> /usr/sbin/dpkg-statoverride
> /usr/sbin/dpkg-divert

I've mostly rewritten mksplit and the two dpkg-* ones in C, need to
refactor some of the dpkg code to avoid duplication, and do some
testing. Next is u-a.

> All but chkdupexe are in the dpkg package. No external modules are used
> by scriptreplay, chkdupexe, and mksplit. The only module outside
> perl-base that is used by the others is Locale::gettext. 

> All but cleanup-info set PERL_DL_NONLAZY in their Lenny versions, which
> makes the "eval 'use Locale::gettext'" call fail due to missing symbols
> when liblocale-gettext-perl and perl-base are out of sync.

> If /usr/sbin/cleanup-info is considered part of the Essential
> functionality of dpkg, it also needs to set PERL_DL_NONLAZY.
> Judging by /usr/share/doc/dpkg/README.feature-removal-schedule,
> that is probably not the case.

Right, cleanup-info should be considered an internal program for dpkg
maintainer scripts to fix the mess created by an ancient install-info.
No other program should be calling it, and as you mentioned we are
going to remove it post-lenny.

> Post-lenny, I see two options that don't involve changing the module path:
> - mandate that ABI changes in the Perl XS module interface
>   will always be accompanied with a symbol rename caught by
>   PERL_DL_NONLAZY, and artificially do that for Debian if needed in the
>   future. This practically means "just carry on and hope we don't have
>   to deviate from perl upstream".
> - integrate Locale::gettext in perl-base (#479681) and mandate that
>   Essential:yes programs may not load non-Essential XS modules even
>   opportunistically (inside an eval block) because PERL_DL_NONLAZY
>   can't be trusted.  This seems to be the safer option of the two.

There's a third option, ban usage of perl-base inside essential. I think
this is the best option, makes life easier for embedded systems, and
might prepare the path to take perl-base out of essential, if so


Reply to: