Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
Thomas Bächler wrote: Andreas Radke schrieb: You must have mixed the mailing lists! Actually, no. Arch64 was founded to never have support for 32bit compatibilty. So move this into the community/AUR list. Yeah, maybe, and I am extending it. I give you a strict -1 for any 32bit compat stuff in our officially supported repos as I already told you in private discussions. I've spent several weeks if not even months to make it as clean as possible. What you are saying is that by adding an extra capability (again, separate repository, nothing to pollute core or extra in any way), we destroy the clean-ness of your so clean (and yeah, it is clean) system. That's just irrational. The fact that you don't quote a single line from my posting tells me that you haven't even read any of my propositions. Why don't you give technical arguments instead of making this personal? The reason I want to maintain this on our ftp is that I want it to be easily accessible to our devs and users, as I can't maintain it alone. The reason I don't want this (at least the core of it) in community is that I want it to be separate from the rest. Besides, unless you want to maintain the packages or use them by activating the repository in pacman.conf, you won't even notice it's there. It would be a reason for me to stepdown here! Now you're just being childish! 100% agree with Andreas, again this is about principles. And I think Andreas has the same principles as me, either you go full x86-64 or you don't. A middle road is messy. If it were up to me the kernel wouldn't even have support for executing 32 bit stuff (right now that option is enabled). Glenn
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
On Tue, Jul 08, 2008 at 02:25:44PM -0500, Aaron Griffin wrote: > I have to side with Thomas here on the fact that no technical > arguments were brought up. That irks me just a bit - that "no because > no" seems to be a valid reason. It's not. > > That said, I am very very neutral on this. Thomas' plan does not > integrate anything at all, it just puts some 32bit libs in a parallel > repo for people to use if they want to (read: users can choose). A > pristine system is all well and good, but as we can all tell from the > existence of the lib32- packages in community, it's not what everyone > wants. What Thomas is proposing is keeping the pristine system > pristine unless someone wants to install the 32bit stuff. I don't have > a problem with this rationale. > > *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. Well there's nothing stopping people from creating their own 32bit library repos for x86_64. So just get together and do it eh? That's why there are things like kdemod and a new arch-games repo.
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
Thomas Bächler wrote: Andreas Radke schrieb: It's more a question what Arch64 was founded for: to be the bleading edge leading _pure_ 64bit distro around. That's been its goal since the project has started. And I think we did a good job. You may have missed the early discussions when we made decisions that we don't want (though we have could have) multilib compatibility and bi-arch gcc. That was a strict law. It was our way to push the efforts to once get it the same level where the x86 world is. I missed the discussions, maybe. But this is not a discussion we had a few years ago, this is the discussion we are having now. And just saying "A few years ago, we wanted it this way" is not a good reason. Offering 32bit compat stuff always means to make it easy for users No, not to make it easy, but make it possible. As I said in my reply to Daniel, I need a 64 bit OS, but I also need mixed 32/64 bit environments. but takes much pressure from companies and opensource developers give the x86_64 architecture the time and responsibility it is worth. You can compare it to the question to support closed source stuff or not. We made our decision long ago. So please respect it. We never denied closed source software out of principle. We always made things "just work". I want standard applications to "just work", without having to bother about which architecture I am on. Now, again, you gave me a list of ideological reasons not to do it, but where exactly is the point where this damages your "pure" system technically? It's about the technical purity. It's this that makes us different from the other distro's. Otherwise we're just on the road to the next ubuntu. And if you really want 32 bit stuff running on x86-64, just use a 32 bit chroot and don't bother with the multilib stuff. Glenn
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
On Tue 2008-07-08 23:38, RedShift wrote: > Thomas Bächler wrote: > [...] >> Now, again, you gave me a list of ideological reasons not to do it, but >> where exactly is the point where this damages your "pure" system >> technically? > > It's about the technical purity. It's this that makes us different > from the other distro's. Otherwise we're just on the road to the next > ubuntu. And if you really want 32 bit stuff running on x86-64, just > use a 32 bit chroot and don't bother with the multilib stuff. Well, I see a lot of lib32-* packages in the [community] repo, this means people do want this stuff; at the same time, lib32 packages kind of suck (just read a PKGBUILD to find out why). Arch always provided closed-source software too, so there is no such "purity" to maintain. Thomas proposed to create an ad-hoc repo, so the *-32bit won't even pollute the official repos, I don't see how cleaner this could be; If you don't enable it, then it won't affect your system at all. P.s. There should be a Godwin's-like Law for the phrase "we are on the road to Ubuntu"... -- Alessio (molok) Bolognino Please send personal email to [EMAIL PROTECTED] Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB pgprvoPPwfeCH.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
> It's about the technical purity. It's this that makes us different from the > other distro's. Otherwise we're just on the road to the next ubuntu. And if > you really want 32 bit stuff running on x86-64, just use a 32 bit chroot and > don't bother with the multilib stuff. It's not at all about technical purity. This makes no changes to Arch 64, it's separate. Arch64 remains pure. Technically, it's better than the existing lib32 efforts too. Let's be realistic here. A computer is a tool to be used. Not that great a tool if it doesnt do what you need it to. Some people need flash and other closed source things. +1
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
James Rayner wrote: It's about the technical purity. It's this that makes us different from the other distro's. Otherwise we're just on the road to the next ubuntu. And if you really want 32 bit stuff running on x86-64, just use a 32 bit chroot and don't bother with the multilib stuff. It's not at all about technical purity. This makes no changes to Arch 64, it's separate. Arch64 remains pure. Technically, it's better than the existing lib32 efforts too. Let's be realistic here. A computer is a tool to be used. Not that great a tool if it doesnt do what you need it to. Some people need flash and other closed source things. +1 Im with James here and i can help test things if needed. +1 -- Douglas Soares de Andrade -- ThreePointsWeb - www.threepointsweb.com -- Python, Zope e Plone == Archlinux Trusted User - dsa ** Quote: Old programmers never die; they exit to a higher shell.
[arch-general] latex2rtf missing URL
Hi, i was about to file a bug report cause in the web interface latex2rtf is missing the URL string, but then when i browsed SVN i saw that the package included a URL address. So i decided to send this email instead. Is that a bug of the web interface? I dont remember a similar occassion in the past. Greg