Re: Bug#397917: gsynaptics - lists s390 as supported
On Sat, Nov 11, 2006 at 10:20:47AM +0900, Osamu Aoki wrote:
> > > Anyone have suggestion?
> > One possibility is to list the package as Architecture: any, but construct
> > your debian/rules file such that the package fails to build if the
> > architecture is s390.
> That may be a good solution if I did not have package in testing
> including s390. But it is there.
> It will waste of autobuilder time and current package stays in testing
> and unstable for s390.
Uh, no. You need to fix your package to *not* build on s390, and *then* you
can request that the ftp team remove the broken s390 binary from the
archive.
It needs to be done in this order, because if your package is not fixed so
that the source prevents building on the architectures where it's not
supposed to be built, there is a risk that the package will get rebuilt (by
an autobuilder, or by someone being cute), and then the ftp team removal
will have been for nothing.
> As I see now, I have few options. What is right?
> Option 1)
> * Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal"
Wrong.
> * Reassign #397917 to xserver-xorg-input-synaptics
Wrong.
> * Ask xserver-xorg-input-synaptics to be rebuild as Architecture: any .
Wrong.
> I know it is unlikely to hook synaptics device to s390 but then who
> will ever bother to set up xserver to start with.
No, it is *impossible* to hook a synaptics device to s390.
> I understand that it is likely to have s390 run X client softwares on it
> and some X server to be connected to it for display. I see X server on
> s390 so I see no reason not to build xserver-xorg-input-synaptics.
The only X server packages built on s390 are xvfb, xserver-xephyr, and
xnest. None of these operate on real hardware, and none of them can be used
with xserver-xorg-input-synaptics.
> Option 2)
> * Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal"
> * Lazily sit tight.
Wrong.
> Option 3)
> * Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc"
> * Ask ftp-master for removal of package for s390
> * Make entry in quinn-diff not to build on s390
This is an acceptable solution,
> This is a lot of CPU time and work for no real gain other than closing
> bug.
The gain is that it removes a useless package from the archive, saving us a
small amount of archive space and improves the experience of s390 users.
> Option 4)
> * Set "Architecture: any"
> * Have fancy script to fail in s390.
> * Ask ftp-master for removal of package for s390
> * Make entry in quinn-diff not to build on s390
This is an acceptable solution.
> PS: Many device support packages are almost useless for
> non-PC/workstation like hardware. This goes with arm and mips too.
No, you're missing the point. The S/390 port has *no hardware*; in the case
of other architectures, some user *may* hook a synaptics device up to their
computer, but on s390 this is not possible at all because of what s390 is.
Even if the S/390 VM was enhanced somehow to support hooks for this class of
physical hardware, the kernel has no support for it.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: