Re: [aur-general] AUR and unsuported architectures
On Mon, Jun 4, 2012 at 2:12 AM, Martti Kühne mysat...@gmail.com wrote: On Sun, Jun 03, 2012 at 08:52:39PM -0300, Hugo Osvaldo Barrera wrote: But that would simply add arm or ppc to the ARCH array. The point is to know beforehand if the package works - currently I can know if a package works or not in my arch (amd64) by looking at the PKGBUILD. That's the whole point of that array. Ultimately it sounds like a good idea to set up a modified AUR for each of initially mirrors and modifies the arch of the current, later incoming packages to aur and then let them be adopted by the people who use the arches. Then, after the situation has fully surfaced, the beforehand-clause would be satisfied. Only few modificaitons are actually needed, like a field untested or something to indicate a package hasn't been acted upon or verified since the automatic conversion. If a user finds a verified, he might be able to unverify a package or be requested to use the comments section. In a generalized approach this could solve even more of the current issues mentioned with aur, if it would incrementalize by version, per-arch-diffs and per-taco-diffs... making pkgbuilds patchwork. :) Is there an official consensus about this question? I was asked to include 'arm' to the architecture array in fish-shell-git. I have no problems with that, but want to conform to the general recommendations.
Re: [aur-general] AUR and unsuported architectures
[2012-07-21 10:15:55 +0200] SanskritFritz: Is there an official consensus about this question? No. I was asked to include 'arm' to the architecture array in fish-shell-git. I have no problems with that, but want to conform to the general recommendations. I would do it and think you should too if this brings little to no maintenance burden. -- Gaetan
Re: [aur-general] AUR and unsuported architectures
On Wed, May 30, 2012 at 08:58:57PM -0300, Hugo Osvaldo Barrera wrote: I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array? What about a modded aur client, I could write a patch to about any given aur helper within minutes that would add the arch to the PKGBUILD after download, which would simply add/enforce the desired arch. I mean, it seems a silly answer to a question that raises somewhat complex concerns, but since arch guys like to homebrew things anyway, this seems to be what I'd just do. cheers! mar77i
Re: [aur-general] AUR and unsuported architectures
On Mon, Jun 04, 2012 at 01:38:01AM +0200, Martti Kühne wrote: What about a modded aur client, I could write a patch to about any given aur helper within minutes that would add the arch to the PKGBUILD after download, which would simply add/enforce the desired arch. Excuse my inability to ignore the mess in that sentence. What about a modded aur client, I could write a patch to about any given aur helper within minutes that would modify the PKGUBILD after download, and add/enforce the desired arch, giving it a shot in the dark. ...Also, one would find out soon enough if modifications are needed. cheers! mar77i
Re: [aur-general] AUR and unsuported architectures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-03 20:44, Martti Kühne wrote: On Mon, Jun 04, 2012 at 01:38:01AM +0200, Martti Kühne wrote: What about a modded aur client, I could write a patch to about any given aur helper within minutes that would add the arch to the PKGBUILD after download, which would simply add/enforce the desired arch. Excuse my inability to ignore the mess in that sentence. What about a modded aur client, I could write a patch to about any given aur helper within minutes that would modify the PKGUBILD after download, and add/enforce the desired arch, giving it a shot in the dark. ...Also, one would find out soon enough if modifications are needed. cheers! mar77i But that would simply add arm or ppc to the ARCH array. The point is to know beforehand if the package works - currently I can know if a package works or not in my arch (amd64) by looking at the PKGBUILD. That's the whole point of that array. - -- Hugo Osvaldo Barrera -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPy/jFAAoJEIc88gcb++1EWz4H/iJ5gbJLFzK0vrQMeKhOu1H3 V4RPlyzrEOezt3ZV4LX7GWoKcgjIkWR8GR31KSsDoOlPgsy/ejsAw6D0GiUpHhly DG924wFkYOrPUIYuacIFnEZGwLiTh9zObCPe2tQEczW4OGM5I4tvkyXB4YqtNu0v 8YA+DwMo3+mzX1a2MHx2jjVHYsbKWXapR9SEe4tG7O8Cl1QssIQEkwMneheeeuXt h+ZuwGIWjL8E8r99cvCQDdJ6SWUdDQAjVtGnS1cOKauWsNxyqbCGRZRs8ln6pErP H10ya8lGjwgHMcTVeqC1/mraEuzIO8oZWFloMqahh0on8Dvg6wFO5GBjl6kwTPA= =Br/F -END PGP SIGNATURE-
Re: [aur-general] AUR and unsuported architectures
On Sun, Jun 03, 2012 at 08:52:39PM -0300, Hugo Osvaldo Barrera wrote: But that would simply add arm or ppc to the ARCH array. The point is to know beforehand if the package works - currently I can know if a package works or not in my arch (amd64) by looking at the PKGBUILD. That's the whole point of that array. Ultimately it sounds like a good idea to set up a modified AUR for each of initially mirrors and modifies the arch of the current, later incoming packages to aur and then let them be adopted by the people who use the arches. Then, after the situation has fully surfaced, the beforehand-clause would be satisfied. Only few modificaitons are actually needed, like a field untested or something to indicate a package hasn't been acted upon or verified since the automatic conversion. If a user finds a verified, he might be able to unverify a package or be requested to use the comments section. In a generalized approach this could solve even more of the current issues mentioned with aur, if it would incrementalize by version, per-arch-diffs and per-taco-diffs... making pkgbuilds patchwork. :) cheers! mar77i
Re: [aur-general] AUR and unsuported architectures
On 01/06/12 02:31, Loui Chang wrote: On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote: On 2012-05-31 08:10, Phillip Smith wrote: On 31 May 2012 17:38, Jelle van der Waa je...@vdwaa.nl wrote: When I first though about it, I wanted to say why not, it doesn't hurt the functioning of the normal i686,x86_64 packages. I thought the same, but after thinking more... While AUR is unsupported, the project/site is still an official item. In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not. We don't encourage documentation of other platforms in our wiki (do we?) While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures. I'm not a TU, but I actually think allowing other architectures in the PKGBUILDs is a Good Thing. The AUR is supposed be be a place of less-restricted user contribution - where packages (and/or architectures?) that developers are not interested in can be submitted. Sure it's not a problem or against the rules. I'm just afraid that ARM users will use the AUR and then complain that stuff doesn't work. As I have seen with for example archbang and archlinuxarm questions on #archlinux. It may be a bit of chicken-and-egg, though. The ppc/arm userbase might grow if arch is seen stable enough and seems to have sufficient packages, possibly making it worth being supported, but the lack of infrastructure won't make that so possible. Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into the main Arch collective, and adding their technological distinctiveness to our own. -- Jelle van der Waa
Re: [aur-general] AUR and unsuported architectures
Loui Chang wrote: It may be a bit of chicken-and-egg, though. The ppc/arm userbase might grow if arch is seen stable enough and seems to have sufficient packages, possibly making it worth being supported, but the lack of infrastructure won't make that so possible. Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into the main Arch collective, and adding their technological distinctiveness to our own. I think that other architectures should be allowed to peacefully coexist in the AUR. Some of them may gain enough momentum to get official support (which will also require either new devs coming in or existing devs getting currently unsupported hardware). Until that happens, it should be made clear on the site that other architectures are not officially supported and that users cannot expect help with them. They can still seek help in the Other Architectures area of the forum, the existence of which is itself somewhat supportive of allowing other architectures. If we did that then we would have to emphasize that architecture-specific packages are only allowed when the included modification is necessary for full functionality. The rest of this message is mostly a train of thought that I cut out from the preceding part. At first I thought to propose a naming scheme for architecture-specific packages similar to VCS or programming language module packages, but that would be messy. The real problem is that each architecture has a different namespace for packages. It just so happens that i686 and x86_64 packages often require no changes, so we can use the same PGKBUILD for both. I doubt that there is any impetus for it, but the ideal solution would be to separate the namespaces in ABS and AUR. Most PKGBUILDs would remain the same. Packages for multiple architectures would be copied into each namespace (e.g. arch=(i686 x86_64) would be copied to i686 and x86_64). This is what happens with built packages already, but the PKGBUILDs are still jumbled together in ABS and AUR for convenience|laziness|tradition|tacos. The real change would be that instead of having PKGBUILDs with complicated if-then-else blocks to handle architecture, we would have PKGBUILDs for each architecture *in those cases*, i.e. when changes are required for a particular architecture. Or maybe we could just use the current split PKGBUILD framework for doing something similar, with architecture-specific packages named foo-arch in the PKGBUILD. Meh, I'm mostly thinking out loud here. The point was simply that there would be a way to have a namespace for unsupported architectures living side-by-side with the supported ones. Ultimately I still think that it's unfortunate that all of the metadata is locked up in Bash. It difficilitates the creation of many practical metapackaging tools. If anyone wants to play around with this idea, reply in a new thread. I've left this in the old one because I don't expect any real discussion, but it might be interesting.
Re: [aur-general] AUR and unsuported architectures
On 2012-06-01 03:17, Jelle van der Waa wrote: On 01/06/12 02:31, Loui Chang wrote: On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote: On 2012-05-31 08:10, Phillip Smith wrote: On 31 May 2012 17:38, Jelle van der Waa je...@vdwaa.nl wrote: When I first though about it, I wanted to say why not, it doesn't hurt the functioning of the normal i686,x86_64 packages. I thought the same, but after thinking more... While AUR is unsupported, the project/site is still an official item. I agree, this is quite true, and I actually must agree that ppc/arm would be out-of-place because of this. In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not. We don't encourage documentation of other platforms in our wiki (do we?) I don't know if it's allowed, but I should point that this article exists in the wiki: https://wiki.archlinux.org/index.php/Official_Install_Guide_on_a_PowerPC I don't think it should say official. Or it should at least mention it's unsupported by arch, BTW. While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures. I'm not a TU, but I actually think allowing other architectures in the PKGBUILDs is a Good Thing. The AUR is supposed be be a place of less-restricted user contribution - where packages (and/or architectures?) that developers are not interested in can be submitted. Sure it's not a problem or against the rules. I'm just afraid that ARM users will use the AUR and then complain that stuff doesn't work. I've seen people complaining that pacman can't install stuff from AUR too. We can't let out-of-place users become an impediment to move forward. As I have seen with for example archbang and archlinuxarm questions on #archlinux. I've seen Ubuntu and Fedora users asking stuff in #debian. Stupid people will always be stupid, you can't stop that! The other reasons mentioned are valid (and I had actually backed down because of them), but I don't think this one should really have as much weight. It may be a bit of chicken-and-egg, though. The ppc/arm userbase might grow if arch is seen stable enough and seems to have sufficient packages, possibly making it worth being supported, but the lack of infrastructure won't make that so possible. Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into the main Arch collective, and adding their technological distinctiveness to our own. Given that this question (is arm/ppc allowed in AUR?) has had a bit of mixed responses, can I expect a bit more of discussion on this, or should I consider the no final? Thanks, -- Hugo Osvaldo Barrera
Re: [aur-general] AUR and unsuported architectures
On 01/06/12 08:17 PM, Hugo Osvaldo Barrera wrote:
Given that this question (is arm/ppc allowed in AUR?) has had a bit
of mixed responses, can I expect a bit more of discussion on this, or
should I consider the no final? Thanks,
I wouldn't consider the no final. If you put a PKGBUILD in the AUR
that says arch=('i686', 'x86_64' 'arm' 'ppc') and someone requests that
it be deleted for that reason, I'm not going to delete it.
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] AUR and unsuported architectures
On 2 June 2012 11:21, Connor Behan connor.be...@gmail.com wrote:
On 01/06/12 08:17 PM, Hugo Osvaldo Barrera wrote:
Given that this question (is arm/ppc allowed in AUR?) has had a bit
of mixed responses, can I expect a bit more of discussion on this, or
should I consider the no final? Thanks,
I wouldn't consider the no final. If you put a PKGBUILD in the AUR
that says arch=('i686', 'x86_64' 'arm' 'ppc') and someone requests that
it be deleted for that reason, I'm not going to delete it.
Look at it this way: why the hell should it matter to me if I'm not an
'arm' or 'ppc' user? The build would go just fine, and if I never look
at the PKGBUILD, then nothing is different to me. So in the end,
there's nothing wrong with that if the same PKGBUILD can be used
across platforms.
--
GPG/PGP ID: C0711BF1
Re: [aur-general] AUR and unsuported architectures
On 31/05/12 01:58, Hugo Osvaldo Barrera wrote: Hi, I've recently seen some comments in AUR, where a user points out that X package works well on powerpc/arm. I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array? If it is ok, is it *advised* to do so when apropriate? Supported architectures should see absolutely no change regarding these packages, and unsupported one will benefit from it. Again, being AUR unsupported anyway, I see nothing bad out of this, but I'd like to know the TU's stance on this, especially since I'm about to install archlinuxppc on one of my laptops. :) Cheers, thanks, When I first though about it, I wanted to say why not, it doesn't hurt the functioning of the normal i686,x86_64 packages. Except there might be a few drawbacks: * Become a place where ARM/PPC/* will look for support * ARM/PPC/* Folks might want to add patches specific for their architecture to AUR packages. -- Jelle van der Waa
Re: [aur-general] AUR and unsuported architectures
And could it potentially lead to AUR packages uploaded without either 'i686' or 'x86_64' set? On Thu, May 31, 2012 at 09:38:05AM +0200, Jelle van der Waa wrote: On 31/05/12 01:58, Hugo Osvaldo Barrera wrote: Hi, I've recently seen some comments in AUR, where a user points out that X package works well on powerpc/arm. I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array? If it is ok, is it *advised* to do so when apropriate? Supported architectures should see absolutely no change regarding these packages, and unsupported one will benefit from it. Again, being AUR unsupported anyway, I see nothing bad out of this, but I'd like to know the TU's stance on this, especially since I'm about to install archlinuxppc on one of my laptops. :) Cheers, thanks, When I first though about it, I wanted to say why not, it doesn't hurt the functioning of the normal i686,x86_64 packages. Except there might be a few drawbacks: * Become a place where ARM/PPC/* will look for support * ARM/PPC/* Folks might want to add patches specific for their architecture to AUR packages. -- Jelle van der Waa
Re: [aur-general] AUR and unsuported architectures
On 31 May 2012 17:38, Jelle van der Waa je...@vdwaa.nl wrote: When I first though about it, I wanted to say why not, it doesn't hurt the functioning of the normal i686,x86_64 packages. I thought the same, but after thinking more... While AUR is unsupported, the project/site is still an official item. In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not. We don't encourage documentation of other platforms in our wiki (do we?)
Re: [aur-general] AUR and unsuported architectures
On Thu, May 31, 2012 at 1:10 PM, Phillip Smith li...@fukawi2.nl wrote: I thought the same, but after thinking more... While AUR is unsupported, the project/site is still an official item. In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not. I agree. -- Sébastien Luttringer www.seblu.net
Re: [aur-general] AUR and unsuported architectures
On 2012-05-31 08:10, Phillip Smith wrote: On 31 May 2012 17:38, Jelle van der Waa je...@vdwaa.nl wrote: When I first though about it, I wanted to say why not, it doesn't hurt the functioning of the normal i686,x86_64 packages. I thought the same, but after thinking more... While AUR is unsupported, the project/site is still an official item. In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not. We don't encourage documentation of other platforms in our wiki (do we?) While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures. It may be a bit of chicken-and-egg, though. The ppc/arm userbase might grow if arch is seen stable enough and seems to have sufficient packages, possibly making it worth being supported, but the lack of infrastructure won't make that so possible. In any case, it's good to know the official stance so I know what to do in these sort of cases. Thanks, -- Hugo Osvaldo Barrera
Re: [aur-general] AUR and unsuported architectures
On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote: On 2012-05-31 08:10, Phillip Smith wrote: On 31 May 2012 17:38, Jelle van der Waa je...@vdwaa.nl wrote: When I first though about it, I wanted to say why not, it doesn't hurt the functioning of the normal i686,x86_64 packages. I thought the same, but after thinking more... While AUR is unsupported, the project/site is still an official item. In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not. We don't encourage documentation of other platforms in our wiki (do we?) While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures. I'm not a TU, but I actually think allowing other architectures in the PKGBUILDs is a Good Thing. The AUR is supposed be be a place of less-restricted user contribution - where packages (and/or architectures?) that developers are not interested in can be submitted. It may be a bit of chicken-and-egg, though. The ppc/arm userbase might grow if arch is seen stable enough and seems to have sufficient packages, possibly making it worth being supported, but the lack of infrastructure won't make that so possible. Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into the main Arch collective, and adding their technological distinctiveness to our own.
[aur-general] AUR and unsuported architectures
Hi, I've recently seen some comments in AUR, where a user points out that X package works well on powerpc/arm. I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array? If it is ok, is it *advised* to do so when apropriate? Supported architectures should see absolutely no change regarding these packages, and unsupported one will benefit from it. Again, being AUR unsupported anyway, I see nothing bad out of this, but I'd like to know the TU's stance on this, especially since I'm about to install archlinuxppc on one of my laptops. :) Cheers, thanks, -- Hugo Osvaldo Barrera
