Re: Bits (Nybbles?) from the Vancouver release team meeting
Andreas Barth <aba@not.so.argh.org> writes:
> * Tollef Fog Heen (tfheen@err.no) [050314 10:55]:
>> * Steve Langasek
>>
>> | If you are planning any other transitions that will affect a lot of
>> | packages, please let us know in advance. We will need to complete the
>> | larger transitions as fast as possible, to get testing back into a
>> | nearly releasable state quickly again after the release.
>
>> Multiarch.
>
> I have yet to see a proposal how to do multiarch in the right way.
> This might be partly related to the fact that I don't follow all lists
> around, but well - this needs to be done.
Proposal is on Tollefs page, let him repeat the url.
> However, given the timeframe, I seriously doubt that we can do multiarch
> in time for etch.
We already have had a fully working toolchain and apt/dpkg with
multiarch support all ready and most of the essential packages patched
to multiarch as well. All of it now has bitrot but Tollef is writing
his thesis on it and is actively working on updating multiarch to the
latest versions and ideas.
Note that multiarch is a package by package thing!
To function only dpkg/apt/aptitude/dselect/... need to be made aware
(apt, dpkg patches available) and libs one doesn't have to Depend on
needs to be ported.
To build for multiple archs on a single host the toolchain has to be
ported (Tollef is working on them first) [this is not required but
important to users, blody anoying not to have].
For the system to be usable to general users all essential libs have
to be ported and as many important/standard libs as possible till
etch. Porting a lib means mostly splitting the packages into all and
any files to allow multiple archs to be coinstalled.
The amount of libs also depends on the arch. For i386/amd64 a lot of
libs are needed to run e.g. galeon 64bit and OOo 32bit. For ppc,
sparc, mips, mipsel and s390 there is probably no point in having
gnome 64bit as it is slower. I can very well see !amd64 multiarch
archs having a limited package list restricting it to packages
benefiting from 64bit address space like mysql/postgresql.
On the timeframe issue:
If it weren't for sarge blocking us we would have submitted multiarch
patches as early as one year ago. Should we start submitting / NMUing
them for _experimental_ now to get this change running and tested? Or
should we keep waiting for sarge getting released and then massfile
them the next week?
Also note that multiarch and non multiarch packages are fully
compatible both ways. Multiarch works on old dpkg (with just one arch)
and non multiarch still works with multiarch dpkg/apt (but limiting
what dpkg lets you install multiarch as old debs conflict). If we add
multiarch patches to etch but then don't do multiarch all we end up
with are some packages split finer than now.
> Cheers,
> Andi
MfG
Goswin
Reply to: