[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: architecture: all but ... (please add armel to architecture list)

block 461088 by 461551

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:

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: