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

Re: powerpc64, multiarch vs biarch and etch ...



Steve Langasek <vorlon@debian.org> writes:

> 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.

No package is currently blocking multiarch compatibility for other
packages. Each and every package can be transformed to multiarch on
its own and uploaded with the exception of actualy setting the
"Multi-Arch:" field. This means:

- split binaries out of library packages as per Policy 8.2 (MUST
  directive)
- split architecture independent files out of -dev packages
- move arch specific conffiles (e.g. list of plugins) into
  arch-os-libc dirs
- move shared objects (libraries) into arch-os-libc dirs

What we (people working on multiarch) need for this is foremost the
cooperation of ftp-master not to block package splits as they have
done with the libc6/libc-bin split a few weeks before. It is realy
anoying for maintainers to do all the work to support multiarch just
so they can get shut down by ftp-master when they are done.

>> 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.
>
> 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.

As Release team you should be able excert some weight to influence
ftp-master behaviour or have they come rouge? :)

MfG
        Goswin



Reply to: