Daniel Isenmann schrieb:
*But* I think it is a bit important that we look at why we're doing this - for a handful (5 or 6) closed source apps. flash, teamspeak, skype, google-earth (and wine). It seems like a lot of work for a handful of apps. That's why I'm neutral on this. I think the rationale is sound, but it sounds like a lot of forward MOTION for little forward PROGRESS.
It is some work, but it is worth it. I want this because my computer is not in an ideal world where I can simply port everything to 64 bit. This is the real world, where I depend on applications I that need 32 bit environments, even worse, I depend on applications that only work in x86_64/i386 multilib environments.
I really don't see the advantage to do this. Like Aaron said, there are just about 5-6 apps, which are not available on x86_64.
See above.
The next thing is, why should we support it official?
You are all so much about terminology. The "official" part is not what this is about, but the "separate" part. I want a clean 32bit environment separate from the "normal" repositories. And if you want to call it [community-multilib] instead of multilib, fine.
There are users out there which are happy with the lib32-* packages in community. The TUs are doing a great job on this.
You haven't really read my posting. The lib32-* packages are broken by design. This is just a lot of work being done, about a good job ... that's another category.
Why should we (we seen as dev) support those stuff?
Well, because I want do, and so do others, possibly. Why should we not support it?
Why not bringing your stuff into community as a replacement for the lib32-* packages? In my opinion setting up an additional official repo just for multilib is too much work, which isn't needed (MY opinion).
1) Setting up a repository is 0 work. 2) Because it doesn't belong in community, it doesn't belong in extra or even in core. It's a different thing and it should be in its own place.