Bug#1012362: transition: luajit
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.
Reply to: