Re: Bits (Nybbles?) from the Vancouver release team meeting
Sven Luther <sven.luther@wanadoo.fr> writes:
> On Mon, Mar 14, 2005 at 10:16:20AM +0000, Martin Michlmayr wrote:
>> * Aurélien Jarno <aurelien@aurel32.net> [2005-03-14 10:56]:
>> > Would it be possible to have a list of such proposed architectures?
>>
>> amd64, s390z, powerpc64, netbsd-i386 and other variants, sh3/sh4, m32r
>
> ppc64 is not currently a candidate for a separate arch, the path to go is a
> biarch solution, much like the current amd64 solution in sarge, as word from
> the main ppc64 developers is that a pure64 solution will be a measurable
> performance hit on power (unlike amd64, which is saddled with a weaker
> instruction set to start with).
>
> One could add per-subarch optimized builds and mirrors too though.
>
> Friendly,
>
> Sven Luther
The way to go is to have a seperate architecture but with a very
limited set of packages. This allows packages to keep the same name
instead of prefixing with the bit with (libc6 instead of lib64c6,
zlib instead of lib64z). This also hides the 64bit packages for users
of ppc32 as their setup would not include the ppc64 architecture.
Multiarch porting needed for i386/amd64 needs every package compiled
for both. People do want pure 64bit amd64 installs. 3rd party
software for i386/amd64 needs a lot of libs, much more than ppc64
would need, and doing those the current biarch way is insane compared
to multiarch. It would also duplicate all those packages as 32bit
amd64 and 64bit i386 package.
And once multiarch is in the source ppc64 just has to start the
buildd. Doing biarch for ppc on top of that would be stupid.
So my suggestion for ppc64 (and all other !amd64 multiarchs) is to
either add lots of packages to p-a-s (more sensible would be a white
list), add lots of packages to NFU in wanna-build or provide a large
no-auto list to the buildds to keep out unneccesary packages and treat
it just like any other arch otherwise.
MfG
Goswin
Reply to: