Re: Further cross-building problems with chatty
On Sun, Oct 31, 2021 at 01:36:41PM +0100, Helmut Grohne wrote:
> 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?
That's a great question; Unfortunately I don't know libpurple well
enough to answer that so I've added the maintainer to this email chain.
Hopefully Richard has some insight here.
>
> 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: