Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
Hi gregor,
On Tue, Oct 15, 2019 at 05:17:02PM +0200, gregor herrmann wrote:
> On Tue, 15 Oct 2019 16:29:31 +0300, Niko Tyni wrote:
> > B. make a real perl-xs-dev package that Depends on libperl5.30, have
> > perl Depend on perl-xs-dev (= ${binary:Version}), and possibly move
> > /usr/lib/<triplet>/perl/cross-config-5.30.0 there
>
> So currently we have:
> - perl 5.30.0-6:
> Depends: perl-base (= 5.30.0-6), perl-modules-5.30 (>= 5.30.0-6), libperl5.30 (= 5.30.0-6)
>
> And then we would have:
> - perl 5.30.0-n:
> Depends: perl-base (= 5.30.0-n), perl-modules-5.30 (>= 5.30.0-n), perl-xs-dev (= 5.30.0-n)
I don't think perl-xs-dev replaces libperl5.NN. It becomes an additional
dependency.
> - perl-xs-dev 5.30.0-n:
> Depends: libperl5.30 (= 5.30.0-n) # or >= ?
Should be =.
> For perl arch:any package (well, for arch:all as well) we currently
> just Build-Depend on 'perl'. If I got the dependency changes above
> right, that would still be enough, as perl-xs-dev gets pulled in, or
> am I missing something? Hm, probably I am, as half of the previous
> discussion was about host and build variants of perl-xs-dev. Anyway,
> I'm optimistic that we mere packagers will get clear instructions :)
Yes, you are missing something here. We do have to touch dependencies of
every perl extension (xs module). "Build-Depends: perl" means that it
doesn't work for cross building. Such a dependency is unsatisfiable,
because it implicitly means perl:$DEB_HOST_ARCH, which depends on
perl-base:$DEB_HOST_ARCH, which is in conflict with
perl-base:$DEB_BUILD_ARCH, which is essential. So we will have to
actually remove "perl" from Build-Depends.
I'm not sure whether replacing perl with perl-xs-dev in Build-Depends
will do. If that keeps building natively, it'll also work for cross. If
something goes missing (some perl modules, build scripts, something
else), you'll likely need a full, native perl. To get that, you need to
use "perl:any" or "perl:native". The difference is subtle. I think :any
works for a little longer (since oldoldoldstable rather than
oldoldstable), but :native is more technically correct. Doesn't really
matter, which one you use.
If you are entirely confused now, try remembering these things:
1. If a source package only builds Arch:all, it is irrelevant to this
discussion and none of the things below apply to it.
2. If a source package "Build-Depends: perl", it doesn't cross build.
We need to remove bare "perl" from Build-Depends of extension
modules.
3. A perl extension module should have "perl-xs-dev" in Build-Depends.
4. If a perl extension doesn't build without a "perl" dependency, it
should have a "perl:native" dependency (in addition "perl-xs-dev").
Source packages that Build-Depend on perl for other reasons than
extension modules shouldn't add perl-xs-dev, but if they only use perl
for build scripts in an architecture-independent way, they should use
perl:native as well.
Yes, this means updating hundreds of packages and I don't expect that
this is completed in time for bullseye. If you start working on this,
prefer working on packages with few dependencies (likely no
libsomething-perl dependencies).
What also helps is putting the <!nocheck> profile to use. I guess that a
large number of libtest-pod-perl build dependencies can be annotated
<!nocheck>. When I try annotating a dependency with <!nocheck>, I
usually use the following approach relying on reproducible builds:
1. Increase the version (and thus SOURCE_DATE_EPOCH) of the package.
2. Perform a regular build and save artifacts.
3. Annotate the relevant build dependency with <!nocheck>.
4. Perform another build setting DEB_BUILD_OPTIONS=nocheck and
DEB_BUILD_PROFILES=nocheck (yes, both).
5. Use diffoscope to compare the resulting .changes files.
The approach can be automated to some extend, but is a noticeable
per-package effort, so good guessing what can be annotated helps a lot.
Hope this helps
Helmut
Reply to: