Re: architecture: all but ... (please add armel to architecture list)
> Now we have several overlapping mechanisms to avoid building packages
> on selected architectures. Worse, we don't have any proper instructions
> explaining which mechaism to use.
>
> 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 immeadetly.
> 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.
> 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 usefull unless misused.
And probably should be used more often for particular kind of packages...
> 3) Wanna-build state not-for-us.
>
> buildd maintainer sets this. From wanna-build docs[1]:
>
> there's 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 my armel short buildd maintainance experience, I 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.
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.
> 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.
Perfectly reasonable IMHO.
> 5) packages-arch-specific [2]
>
> p-a-s makes package never appear in wanna-build. It will
> never by tried to be built on architectures defined there.
> It' maintained by three people who manually update it.
> Any technical advantage this approarch has over n-f-u
> is completly negated by the fact the people who are supposed
> to update it ignore my requests to update it...
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...
> 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.
>
> Osamu, for short term, I suggest using type-handling to generate
> architecture strings.
I guess one can see this as a dynamic case of 1) and 2)?
Cheers
Luk
Reply to: