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

Re: How should stalin be handled on slower architectures?

On Wed, Sep 22, 2004 at 11:44:30PM -0500, Rob Browning wrote:

> Summary: An RC bug has been filed claiming that stalin's source is
>   "too big" and that it shouldn't be built for m68k (and I'd presume
>   arm), though it has been built on both in the past.  So I'd like to
>   figure out what action, if any, would be appropriate.

The bug report isn't about whether the package *should* be built for
m68k and arm, it's about whether it *can* be built for m68k and arm.

> A bit back, a new version of stalin was uploaded which was intended
> for testing.  It has built for i386 and sparc, but hasn't built yet
> for m68k or arm (though we have packages of the previous version for
> both of those architectures).

The packages for m68k were removed from unstable a while ago.

> The arm build was attempted, but failed, most likely because it wasn't 
> given enough time; I asked about extending the build time on arm, but 
> never heard back.

The last successful build on arm took < 3 hours; the most recent build
failure there spent 5 hours trying to compile the C file in question
without finishing it.  There may be a difference in the relative power
of smackdown and netwinder that explains this, or there may be toolchain
differences that account for it.  OTOH, this could also be a sign of a
regression in the stalin sources between 0.9 and 0.9+0.10alpha2.

> While I'm not very inclined to agree that the size of the source is a
> release critical bug, especially since we've already been providing
> packages for those architectures.  I am willing to consider dropping
> support for slower architectures if that's the "right thing to do".

> Thoughts?  Any relevant policy I might have overlooked?

If the current toolchain is less forgiving than the version last used to
build the package on arm, and it's no longer possible to build the
package using the available build environments, we have an RC bug
because we shouldn't ship binaries that we know we can't provide
critical updates for.

If the failure is caused by source changes in stalin itself that make
the package more resource-intensive to build, we again have a serious
bug (though only applicable to unstable) if the arm porters feel it's
not reasonable to accomodate the package's build requirements.

If you and the arm buildd maintainers can't come to an agreement that
lets stalin build again on this architecture, the out-of-date binaries
will need to be removed from the archive by an ftp-master.

FWIW, since the problematic source file is in fact generated by stalin,
and is exemplary of the kind of C code stalin generates in the course of
normal use, I'd question how useful this package is on architectures
that have a hard time building it.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: