Re: powerpc64, multiarch vs biarch and etch ... (Was: bits from the release team: release goals, python, X.org, amd64, timeline)

[Sven Luther <sven.luther@wanadoo.fr>]

On Tue, May 30, 2006 at 02:48:43PM -0700, Steve Langasek wrote:
> On Tue, May 30, 2006 at 01:26:16PM +0200, Sven Luther wrote:
> > On Tue, May 30, 2006 at 12:05:26PM +0200, Andreas Barth wrote:
> 
> > > another month has passed and DebConf happened, so we have a few more
> > > changes to announce.
> 
> > > Release Goals
> > > =============
> 
> > I guess from the above, and previous mails from the multi-arch proposers,
> > that this means that multi-arch is now dead for etch, right ? 
> 
> I don't see that anything in that mail should be interpreted as a statement
> either for or against multiarch in etch.  We certainly aren't going to be
> endorsing 0-day NMUs for multiarch when the current blockers all relate to
> the groundwork that has to be implemented in the base packages -- this is
> work that needs to be done, or at least approved of, by the respective
> maintainers.

Well, this near of the freeze, not speaking about multiarch in that deadline,
clearly kills any chance of having it work forward.

The problem here is that the RMs clearly didn't even mention multi-arch as
etch release goals, despite there being a momentum (which was discouraged,
even though maybe unwillingly) in favour of multiarch, and a clear need for it
(HP was interested, powerpc 64bit needs to present a 64bit userland solution,
etc.).

As you said, the release blockers are nothing that can be solved by any kind
of NMU, but needs to be pushed at higher levels for it to happen, and there
the help of the RMs vote of confidence would help.

Yourself and Andreas spoke about wanting to work on multi-arch in january, but
nothing came of this, right ? 

> > Does this mean that if we want userland powerpc64 support, that we should
> > push biarch version of some of the libs needed by those tools needing
> > 64bit access ?  We already have a few of those in the archive.
> 
> Biarch is a horrible, non-scalable, bletcherous design.  With or without
> multiarch support, the fewer biarch packages there are in the archive, the
> better, IMHO.

Maybe, but biarch are what we have now, and what can be made to work. I asked
this same question 6+ month ago, and you gave me the same reply, and
multi-arch has not progressed an inch since then.

> But I'm not an ftpmaster, so MHO doesn't actually count for much here since
> I'm not the one who decides how many biarch packages are too many.

Yeah, ...

Friendly,

Sven Luther