On Tue, 2022-06-07 at 21:21 +0200, Paul Gevers wrote: > Hi Mo, > > On 07-06-2022 17:36, M. Zhou wrote: > > This should be achievable by patching debian/control > > during build once detected IBM architectures. > > This is not allowed. I currently fail to find where that's written down, > but I'm fairly sure that the relevant parties agree that debian/control > must not be mangled with during build. The ftp-reject list touches upon > it, albeit for a different reason [1]. debian/control has to be > unchanged in source. But, maybe you can try to add two stanza's for the > same binary name, one with the Archs !s390x !ppc64el and another for > s390x and ppc64el. I'm not totally sure if that's allowed and if the > tools handle it well, but may be worth a try.
Indeed that's not allowed, although I should have seen some of such examples years ago IIRC. Apart from that, additional binary package entry with different architecture will be deemed as duplicate: dh: error: debian/control has a duplicate entry for luajit > > IIRC adding new architecture without new binary package > > does not have to go through NEW. > > Indeed, they don't. > > > Does that sound good? > > Yes, except for the part about patching d/control. We'll have to find > another way. An alternative to what I wrote before is a extension of the > description to say that the binary is empty on s390x and ppc64el. So both patching control and double stanza do not work. Currently the only solution that I can think of is to upload a NEW empty dummy source package: src:luajit-ibm-transition * bin:luajit Architecture: ppc64el s390x Depends: luajit2 * ... > Paul > > [1] https://ftp-master.debian.org/REJECT-FAQ.html : debian/control > breakage #2 > """ > which basically means that everything must be defined at the beginning > of the build. > """ Thanks. I was not aware of this.
