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

[Brendan O'Dea]

On 2 June 2011 20:56, Niko Tyni <ntyni at debian.org> wrote:
> Reviewing the discussion, I think that Ian had a valid point and that
> we should revisit the vendorarch directory choice. Brendan (cc'd):
> I'd love to have your thoughts on this.

vendorarch was chosen for simplicity, and consistency with vendorlib.
So long as maintainer scripts use only essential packages, it works
rather well.  The situation of attempting to use packages if possible
was not anticipated, and I'll admit that I was somewhat surprised when
the "eval { require ... }" didn't work as expected.

You certainly could make vendorarch ABI dependent, and perhaps should
to avoid some of the more subtle failures (such as the 64bit issue you
mentioned).  I'm not entirely sure however that it fixes this
particular problem correctly.

The conditional inclusion of Locale::gettext is intended to provide
translations for those who want it, but not force a dependancy on the
package for those who don't.  I suspect that it is not intended to
work around upgrades--there are people for whom the configuration
dialogs suddenly reverting to English mid-upgrade could be as much a
bug as the dynamic link failure.

> First, I see all the dpkg commands in /usr/bin have been rewritten in C
> for squeeze [...]
> The debconf case is sourcing /usr/share/debconf/confmodule.sh, which
> currently tries to load three XS modules: Locale::Gettext, Text::Iconv
> and Text::CharWidth.
>
> Therefore, if any problems remain, they are not going to be solved
> just by integrating Locale::gettext into perl-base.

That is unfortunate.  Changing vendorarch would work around that, but
with the caveats discussed above.

Joey may be able to comment on this issue from the debconf side.  Such
as the status of cdebconf, or the possibility of providing pure-Perl
implementations of the debconf dependencies.

--bod