Re: architecture: all but ... (please add armel to architecture list)
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
Reply to: