Creating package without some particular architecture

I copy interesting info I received from Riku Voipio and Luk Claes on the bug report Bug#461088 for gsynaptics with some minor edits to fit to the wiki.

We have several overlapping mechanisms to avoid building packages on selected architectures. Worse, we don't have any proper instructions explaining which mechanism to use.

For short term generic solution, Riku suggested using "Option 6" to generate architecture strings.

For gsynaptics which can be blocked by xfree86-driver-synaptics, "Option 3" or "Option 4" can be used.

Option 1: Architecture: list in package source

This is what gsynaptics does now. wanna-build will still offer the package to build (why?), but sbuild will fail it immediately. Annoyingly maintainers can't define negations (!s390).

It's still offered for building as it might only be temporary relevant and buildd maintainers and/or porters might want to look into it. sbuild will fail as that's what one expects it to do without changing the Arch-field.

Option 2: Architecture: list on binary section

This is used on packages that build some binary on all archs and some on only selected ones. This is very useful unless misused.

probably should be used more often for particular kind of packages...

Option 3: Wanna-build state not-for-us.

buildd maintainer sets this. From wanna-build docs:

There's a need for a way to list packages for which even an attempt to build isn't required. The first solution to this problem was not-for-us; however, as that is difficult to maintain, not-for-us is deprecated nowadays; autobuilder maintainers should use packages-arch-specific instead.

From Riku's armel short buildd maintenance experience, he can't see why n-f-u is more difficult to maintain. neither n-f-u or p-a-s have any connection to what package maintainer defines in Architecture: strings.

Luk stated "You can't document why it's in n-f-u AFAICS and one can't easily have a listing of packages per issue probably."

Option 4: wanna-build state dep-wait

One option would be to put gsynaptics to dep-wait on xfree86-driver-synaptics. Thus buildd would not try to build it unless xfree86-driver-synaptics becomes some day available on s390. While X on s390 might seem unlikely, stranger things have happened.

Luk stated "Perfectly reasonable IMHO."

Option 5: packages-arch-specific

packages-arch-specific (p-a-s) makes package never appear in wanna-build. It will never by tried to be built on architectures defined there. It is maintained by the Debian Build Daemon support Team who manually update it. Any technical advantage this approach has over n-f-u is completely negated by the fact the people who are supposed to update it ignore my requests to update it... Since it's manually updated, it has gathered a lot of cruft.

%xfree86-driver-synaptics: !s390 # Needs %xserver-xfree86

For some unknown reason, this was not a acceptable solution for gsynaptics/ksynaptics, but was for xfree86-driver-synaptics.

Luk stated "It is also not being built on other suites then the one were it sometimes is meant not to build anymore... Some updates go quickly, others take time, I guess that's because there are only a few persons who can update it..."

Option 6: type-handling

This is a kludge that has been written to workaround problems in rest of the architecture selection system. In practice it seems to work very well.

Luk stated "I guess one can see this as a dynamic case of "Architecture: list in package source" and "Architecture: list on binary section"?"

CategoryPackaging