On Tue, 15 Oct 2019 19:30:17 +0200, Helmut Grohne wrote:
> > 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.
Thanks, this helps to overcome my confusion a bit.
Not build-depending on perl might be interesting …
And: perl is pulled in by debhelper ("perl:any").
And: we somehow need perl-modules-<version> as well.
> 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.
Ok.
> 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").
I'm very much in favour of finding a simple scheme and not several
options, like:
* arch:all -> B-D: perl
* arch:any -> B-D: perl:native, perl-xs-dev
I hope something like that is possible.
> 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.
See above :)
> 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).
If we have a clear and scriptable pattern I think we can get very far
with uploading those 500 arch:any packages. But we'll see.
> What also helps is putting the <!nocheck> profile to use.
Right, we already started with this.
> 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.
I typically just add the <!nocheck> and build as in your item 4, and
in the rare cases where I guessed wrong and the build fails I remove
it again. - perl packages typically don't build differently, they
just need packages for building or testing or not.
> 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.
Indeed, and with the guessing it's not really much effort.
> Hope this helps
Thanks!
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Steppenwolf: Wild Thing
Attachment:
signature.asc
Description: Digital Signature