Re: Further cross-building problems with chatty
Hi Travis,
On Tue, Oct 26, 2021 at 07:19:13PM -0400, Travis Wrightsman wrote:
> The following packages have unmet dependencies:
> libpurple0:arm64 : Depends: pidgin-data:arm64 (< 2.14.8-z) but it is not installable
> Depends: pidgin-data:arm64 (>= 2.14.8) but it is not installable
I confirm what josch and the hinter said: pidgin-data should be
m-a:foreign.
> Depends: perl-base:arm64 but it is not installable
> Depends: perlapi-5.32.1:arm64
> E: Unable to correct problems, you have held broken packages.
> E: pbuilder-satisfydepends failed.
>
> I believe #828759 relates to this for pidgin-data and #717882 for
> perl-base and perlapi.
Yes, #828759 looks good to me. #717882 looks essentially unfixable to
me.
> I'm not sure on the correct fixes for these packages. It looks like the
> perl bug is especially tricky?
While Niko said something on the perl side, I think we need to better
understand how pidgin/purple uses perl before we can figure out how to
fix it.
How exactly does libpurple0 use perl?
Let me try to answer this. Please confirm or correct and extend my
understanding.
libpurple0 primarily contains libpurple.so.0 to be linked. That library
can be extended with plugins at runtime. One of those plugins is the
perl.so plugin. It actually seems like purple has two plugin mechanisms.
A C/.so based mechanism and a perl-based mechanism that is enabled via
the perl.so plugin. Upon loading a perl-based plugin, a private library
is extended, which enables "use Purple;". As such libpurple0 also
contains a pure perl module Purple backed by a perl extension module
Purple::Purple. In particular, libpurple0 does not use the main perl
interpreter /usr/bin/perl, but it does use libperl.so.N and standard
perl modules.
Now I'm trying to draw conclusions from the above. Any errors in the
above void the below of course.
What libpurple0 really needs is the embeddable perl interpreter and the
perl relevant perl modules. That should result in a dependency on
libperlN.M at least. Indeed, libpurple0 contains such a dependency. Now
the question is: Why it needs those other dependencies? Niko mentioned
the perl policy and ABI, so presumably the version constraint on
libperlN.M generated from dpkg-shlibdeps is insufficient. Unfortunately,
ensuring that constraint using perlapi-VER makes foreign installation
impossible. So if we want to allow embedding a foreign perl interpreter
(which is not the same thing as a foreign /usr/bin/perl), the perl
packaging must change and move the provides of perlapi-VER to some
M-A:same package.
Possibly we can repurpose #717882 to ask for allowing the installation
of a foreign embedded perl interpreter? That seems fixable.
Helmut
Reply to: