Re: sparc64 as a release architecture
Meanwhile, we have been testing the current sparc64 port on several
development machines, both sun4v and sun4u, and the results are really
quite promising: the major packages which we're using are all there,
they are functional and up-to-date, and on identical hardware,
performance is roughly the same or better compared to wheezy.
> In order for sparc64 to become a release architecture, the buildds and
> porter boxes must be maintained by DSA. Currently, all sparc64
> hardware used within Debian is maintained by ports people.
> Unfortunately, the hardware acquisition process at Oracle takes quite
> long which is why we are still stuck in Debian Ports. Sorry.
What's holding us back in migrating some production machines away from
wheezy (and replacing some older sun4u hardware with newer sun4u or
sun4v machines) is not so much that sparc64 is a ports architecture
rather than a release architecture, but that sparc64 as a ports
architecture is limited to the Unstable suite, which is too much of a
The DSA team is demanding the availability of redundant hardware under a
support contract in order to be able to support sparc64 as a release
architecture with a certain quality of service. That is entirely
understandable. Unfortunately, that demand for hardware under a support
contract is also currently preventing us from testing the sparc64 port
against the Testing suite in a more production-like setting, hence
preventing us from providing early feedback on the port, even though the
Testing suite could probably be built quite easily in its current shape,
there was no shortage of hardware offers (without a support contract) to
provide the necessary build capacity, and the level of service proposed
by the DSA team is not currently requested for the sparc64 port.
In fact, there would be nothing wrong with sparc64 being (and staying) a
ports architecture, if it were possible for ports architectures to
support any suite, instead of just Unstable.
Is the build infrastructure and configuration for ports architectures
entirely separate from that for release architectures? If hardware was
promised by Oracle in such a way that the DSA team is confident their
requirements will be met in the near future, would it be possible to
make sparc64 a release architecture now, and start building the Testing
suite on the existing infrastructure? If not, what are the issues
preventing the Testing and Stable suites from being built for ports
architectures, and what is needed to resolve those issues?