[arch-dev-public] Multilib on Archlinux x86_64
Thomas Bächler
thomas at archlinux.org
Tue Jul 8 17:14:04 EDT 2008
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20080708/2cd791de/attachment.pgp>
More information about the arch-dev-public
mailing list