Multilib in Extras repo?

[Jeremy Katz]

On Mon, 2006-08-21 at 14:09 +0200, Michael Schwendt wrote:
> I've looked a bit into preparing the Extras push script for multilib
> support. In particular:

Thanks a lot for looking into this -- it's something I've been meaning
to do, but just haven't gotten enough round 'tuits. :-/

>  - Find all multicompat -devel binary rpms (considering virtual packages
>    and ExcludeArch) and copy them to their multilib capable arch repository,
>    e.g. (i386/i586/i686/athlon -> x86_64).
> 
>  - Examine the unresolved dependencies of the multicompat packages and
>    copy all missing Extras packages into the target repository, too.
> 
> For the dep resolving, I've used the Yum back-end's returnPackagesByDep()
> method. Although the results look reasonable -- i.e. I see the -devel
> packages pull it their mother packages and all their deps in Extras --
> I'm not an expert in Yum API programming and have yet to find out what
> corner-cases one may need to deal with (Obsoletes? arch/multiarch
> package picking extra-burden?) and what other pitfalls may be lurking.

This is what we do for Core with the addition of also having a
whitelist/blacklist (so that relevant non -devel packages, eg, things
with gtk+ or pam modules can be included).  

> Has anyone else spent thoughts on this? Too late for FE6?
> 
> What is the estimated multilib readiness of FE6? Do we expect
> many file conflicts (due to arch-specific stuff in generated
> headers) or package installer/updater problems (on multilib
> installations)?

I expect a fair bit of conflicts both on the runtime and the -devel
side... unfortunately, the only way to really be able to say for sure is
to actually check the packages.  

My initial thought was to enable something along these lines for Extras
devel right after FC6 came out to give time for things to shake out.  I
could be convinced that doing it now for FE6 and getting things into
shape is the right answer, though

Jeremy