Re: Perl symbol problem - release critical (Re: Bug#489132)
Hi,
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
desired.
regards,
guillem
Reply to: