block 461088 by 461551 thanks On Sat, Jan 19, 2008 at 09:58:08PM +0900, Osamu Aoki wrote: > > gsynaptics lists s390 as supported (Architecture: any) but > > xserver-xorg-input-synaptics is not available. This leads to > > uninstallable binary packages.
> > Bastian > With serious tag and him being s390 buildd maintainer, I took situation > as that the s390 buildd maintainer (Bastian Blank) will not build > xserver-xorg-input-synaptics with some good reason thus the only way for > me is not to build gsynaptics. For me, it looked like that gsynaptic > being so much special as an input device aimed for consumer oriented > system hardware, s390 system being data server oriented may have some > hardware issues to support such thing. (You know that under the normal > situation, people access s390 system running X-client program from > external X-server. Not the other way.) Yes, it is clearly reasonable to avoid building gsynaptics on s390. However, it should not come with the expense of getting it not built on architectures where it could potentially be usefull. > The xserver-xorg-input-synaptics comes from source package > xfree86-driver-synaptics which has Architecture: alpha amd64 arm hppa > i386 ia64 m68k mips mipsel powerpc sparc > (See > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xfree86-driver-synaptics) > I do not see armel here either. So fixing my package only will cause the same > issue and response from the s390 buildd maintainer. I filed a bug against this, and made it blocker of this bug. I really don't like packages setting hardcoded lists of architectures. 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). 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. 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. 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. 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... 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. 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. [1] http://www.debian.org/devel/buildd/wanna-build-states [1] http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.731&root=dak&view=markup -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
