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