FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-03-2008, 07:11 PM
Ian Jackson
 
Default Perl symbol problem - release critical ( Bug#489132)

Raphael Hertzog writes ("Bug#489132: lenny release notes, upgrade dpkg first"):
> To work-around a problem that can happen in the perl 5.10 upgrade (see
> #479711), the perl scripts contained in dpkg (update-alternatives,
> dpkg-divert) have been modified... but for the work-around to be used, the
> new dpkg must obviously be installed first, before the dist-upgrade.

I don't think this is the right solution. To be honest I'm just
astonished at this situation, which is terrible. It is the
consequence of a mistake in the Debian Perl policy - a mistake which
has caused trouble on every previous upgrade, too.


Here is a summary of the problem:

Perl extensions (XS modules) are not compatible across Perl versions
due to ABI changes. For this reason Perl upstream put the Perl
version number in the paths at which modules are installed. The
Debian Perl maintainer has decided not to do this.

As a result, if you try to load a Perl extension from a script when
the versions of the Perl interpreter (in perl-base) and the module
(in a different package) are incompatible, you are trying to load a
library .so with an incompatible ABI.

As it happens, because of lazy symbol resolution, this is detected
very late: after Perl thinks it has loaded the module, the runtime
linker finds a missing symbol and has no option but to kill the
process.

(If it weren't for that, then loading the library would fail; the
Essential scripts which are trying to load the module will then fall
back, so the system would remain functional in a basic way and could
recover.)

As a result, it is possible for a situation to arise where Essential
scripts in the dpkg package (and presumably in other packages) don't
work, without any of the dependencies having been violated. Unless
you're an expert, once your system is in this state you're hosed.


Some observations and opinions:

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

* 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:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#85
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#120
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.)

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

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

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


Possible solutions that I see for lenny:

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.

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.

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

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 ?

Perhaps someone has some other ideas.


Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-03-2008, 07:44 PM
Don Armstrong
 
Default Perl symbol problem - release critical ( Bug#489132)

On Thu, 03 Jul 2008, Ian Jackson wrote:
> * Suppressing lazy symbol resolution may work in this case, but it
> is not correct.

Lazy symbol resolution should be supressed while in eval regardless of
the method which we use to resolve this problem. Non-recoverable
failures from code in eval should be minimized to the extent possible.

While there are other API/ABI differences that may not be caught,
catching the obvious ones is better than catching none at all.


Don Armstrong

--
Love is... a complex sequence of neurochemical reactions that makes
people behave like idiots. It's similar to intoxication, but the
hangover's even worse.
-- J. Jacques _Questionable Content_ #1039
http://www.questionablecontent.net/view.php?comic=1039

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-03-2008, 08:17 PM
Raphael Hertzog
 
Default Perl symbol problem - release critical ( Bug#489132)

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:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#85
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#120
> 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
compatible with.

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
symbol resolution).

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

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

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
installed

> 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
PERL_DL_NONLAZY=1
export PERL_DL_NONLAZY
# Since there is no FrontEnd, this program execs a FrontEnd.
# It will then run a new copy of $0 that can talk to it.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-04-2008, 01:21 AM
"Brendan O'Dea"
 
Default Perl symbol problem - release critical ( Bug#489132)

On Fri, Jul 4, 2008 at 6:17 AM, Raphael Hertzog <hertzog@debian.org> wrote:
> 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

I'm inclined at this point to follow this suggestion.

--bod


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 08-03-2008, 06:31 PM
Niko Tyni
 
Default Perl symbol problem - release critical ( 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 08-20-2008, 09:52 PM
Niko Tyni
 
Default Perl symbol problem - release critical ( Bug#489132)

On Thu, Jul 03, 2008 at 08:11:05PM +0100, Ian Jackson wrote:
> Raphael Hertzog writes ("Bug#489132: lenny release notes, upgrade dpkg first"):
> > To work-around a problem that can happen in the perl 5.10 upgrade (see
> > #479711), the perl scripts contained in dpkg (update-alternatives,
> > dpkg-divert) have been modified... but for the work-around to be used, the
> > new dpkg must obviously be installed first, before the dist-upgrade.
>
> I don't think this is the right solution. To be honest I'm just
> astonished at this situation, which is terrible. It is the
> consequence of a mistake in the Debian Perl policy - a mistake which
> has caused trouble on every previous upgrade, too.

Revisiting this; #489132 and #488300 are still open and I'm (hopefully)
less confused about the issue now than in my earlier reply to #489132
and others.

Summary: I think making perl-base Pre-Depend on dpkg (>= 1.4.20) is enough
to fix this for lenny.

> Possible solutions that I see for lenny:

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

The only perl scripts provided by Essential packages are

/usr/bin/scriptreplay
/usr/lib/dpkg/mksplit
/usr/sbin/cleanup-info
/usr/sbin/install-info
/usr/sbin/update-alternatives
/usr/sbin/dpkg-statoverride
/usr/sbin/dpkg-divert
/usr/bin/chkdupexe

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.

The Lenny version of liblocale-gettext-perl Pre-Depends on
perl-base (>= 5.10.0-9). This makes it impossible for the Etch version
of /usr/bin/perl to see the Lenny version of Locale::gettext.

The other way around is still possible: unpacking perl-base on an Etch
system (after upgrading libc6 etc.) makes Perl 5.10 see the 5.8 version of
Locale::gettext. This breaks the Etch version of the dpkg utilities.

The breakage could be prevented by making perl-base Pre-Depend on dpkg
(>= 1.14.20). I think this would be enough to solve the issue for lenny
and fix #488300 (and possibly #489132, but that one includes some concerns
about the need to upgrade apt manually first.)

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.

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

I think it's clear that Locale::gettext fails to load both ways
when PERL_DL_NONLAZY is set:

- when compiled for 5.10.0 it needs Perl_Istack_sp_ptr from perl/libperl,
which is not present in 5.8.8
- when compiled for 5.8.8 it needs Perl_Tstack_sp_ptr instead,
which is not present in 5.10.0

> (b) regard this as a workaround and do something sensible next
> time.

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.

--
Niko Tyni ntyni@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 08-21-2008, 05:16 PM
Guillem Jover
 
Default Perl symbol problem - release critical ( 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 10:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org