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

Re: [2002-03-03] Release Status Update (shattering myths about porting bugs)



This probably won't get to as many developers as I'd like, but oh
well...

There seems to be a lot of misunderstanding about how to deal with
porting bugs. Here's my feeble attempt at shattering a couple myths.

Myth 1: All porting bugs are RC
Truth: A "package-does-not-compile-on-architecture-X" bug is only
release critical (i.e. severity "serious" and above) if the package
previously built on an architecture, but doesn't do so any more. If a
package has never successfully built on an architecture, it is not
affected (in terms of getting into woody) by the fact that it doesn't
yet work on a particular architecture. Porters *WILL* fill bugs on these,
possibly with patches, but they should be set at severity "important"
(which is not RC)

Myth 2: My package doesn't build on architecture X, so i'll just omit
that from debian/control
Truth: see Myth 1, this is pointless and only makes your package more
difficult to deal with. Autobuilders in general are made to ignore the
Architecture setting in debian/control. 

If you set your debian/control to have:

Architecture: alpha arm i386 ia64 m68k mips mipsel powerpc s390 sh sheb
sparc sparc64

with the sole-purpose of excluding hppa, that is not only ugly, but you
are likely to get bug reports and/or NMUs.

There are *some* legitimate cases where a package is particular to an
architecture (lilo is a good example). But if you find yourself putting
more than a few architectures on the Architecture line, you should think
again very carefully.

<ia64 and hppa plug>
Most porting bugs we've encountered on hppa and ia64 are simple to fix.
We do have slightly more compiler/toolchain problems than, say, i386,
but in the vast majority of the cases the bug is a real porting bug
(using non-standard C++ constructs, using outdated config.{guess,sub},
etc). Debian is fortunate to have 2 ia64 and 2 hppa boxes on the
*.debian.org network. All developers have access to these. Take a few
minutes to make sure your package builds there too, or help fix the 
reported porting bugs.
</ia64 and hppa plug>

randolph
-- 
Debian Developer <tausq@debian.org>
http://www.TauSq.org/

Attachment: pgpkTj1RGjtQr.pgp
Description: PGP signature


Reply to: