Dear Debian cross-builders,
After fixing #996699, the libpurple0 dependency for chatty resolves
correctly during cross-building. Unfortunately this seems to have
uncovered further issues down the dependency chain. I'm now getting the following error while attempting to cross-build chatty with pbuilder:
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
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.
I'm not sure on the correct fixes for these packages. It looks like the
perl bug is especially tricky?
Quoting Travis Wrightsman (2021-10-27 01:19:13)
and #717882 for perl-base and perlapi.
I'm not sure on the correct fixes for these packages. It looks like the perl bug is especially tricky?
I'm adding debian-perl@lists.debian.org to the recipients as I'm not familiar with Perl in a cross-build context. Maybe the Perl maintainers have a solution
for you.
I'm a bit confused that debhelper ${perl:Depends} adds an unversioned dependency on perl-base even though it's essential: https://salsa.debian.org/debian/debhelper/-/blob/main/dh_perl#L152
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
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.
I'm not sure on the correct fixes for these packages. It looks like the
perl bug is especially tricky?
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 292 |
Nodes: | 16 (2 / 14) |
Uptime: | 188:46:03 |
Calls: | 6,616 |
Files: | 12,165 |
Messages: | 5,315,032 |