Package: developers-reference
Version: 3.3.5
Severity: wishlist
After a short discussion on debian-mentors, I have written a section for
developers reference that explains what to do when a package is not
useful, or cannot be built on all architectures. The text is based on
Jeroen's text at http://www.wolffelaar.nl/~jeroen/P-a-s-HOWTO.txt.
Therefore a Cc of this mail goes to him, and we need his approval for
inclusion because the copyright is his.
There is still one thing I do not like about the patch: There doesn't
seem to be a generic address for contacting the "maintainers" of
Packages-arch-specific, and the text lists James Troup and LaMont Jones
by name and personal e-mail-address, instead of some role address. But
it seems that there is no such thing. I suspect that the people who can
change might be just "the buildd admins", but if this is not the same as
the DSA, there isn't a role account for this group, either.
Regards, Frank
Here comes the patch:
***************************************************
--- developers-reference.sgml 25 Mar 2005 15:22:35 -0000 1.263
+++ developers-reference.sgml 29 Mar 2005 15:13:31 -0000
@@ -2879,6 +2879,57 @@
distributions quickly.
</sect2>
+ <sect1 id="packages-arch-specific">When your package is <em>not</em>
portable
+ <p>
+Some packages still have issues with building and/or working on some
+of the architectures supported by Debian, and cannot be ported at all,
+or not with a reasonable amount of time. An example is a package that
+is SVGA-specific (only i386), or uses other hardware-specific features
+not supported on all architectures.
+ </p>
+ <p>
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+ </p>
+ <p>
+ <list>
+ <item>
+ <p>
+First, make sure your package <em>does</em> fail to build on
+architectures that it cannot support. There are a few ways to achieve
+this. One way that you should always use if it is possible, is to have
+a small testsuite during build time, that will test the functionality,
+and fail if it doesn't work. This is a good idea anyway, it can
+prevent some broken uploads.
+ </p>
+ <p>
+Additionally, if you believe the list of supported architectures is
+pretty constant, you should change 'any' to a list of supported
+architectures in debian/control. This way, the build will fail also,
+and indicate this to a human reader without actually trying.
+ </p>
+ <item>
+ <p>
+In order to prevent autobuilders from needlessly trying to build your
+package, it must be included in <file>packages-arch-specific</file>, a
+list used by the <prgn>wanna-build</prgn> script. Mail the
+Packages-arch-specific maintainers for including your package,
+together with why it fails to build. Currently, the people that can
+change that file include LaMont Jones <email>[EMAIL PROTECTED]</email>
+and James Troup <email>[EMAIL PROTECTED]</email>
+ </p>
+ </list>
+ </p>
+ <p>
+Please note that it is insufficient to only add your package to P-a-s
+without making it fail to build on the unsupported architectures: A
+porter or any other person trying to build your package might
+accidently upload it without noticing it doesn't work. If in the past
+some binary packages were uploaded on unsupported architectures,
+request there removal by filing a bug against
+<package>ftp.debian.org</package>
+ </p>
+ </sect1>
<sect id="nmu">Non-Maintainer Uploads (NMUs)
<p>
***************************************************
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
-- no debconf information
--
Frank K�ster
Inst. f. Biochemie der Univ. Z�rich
Debian Developer
