Arch Linux User Repository Requires Packages To Support x86_64: No ARM-Only Software

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • jeisom
    Senior Member
    • Mar 2013
    • 271

    #31
    Originally posted by Espionage724 View Post
    It is Arch based, but isn't part of Arch. Like calling Ubuntu, Debian.

    Comment

    • TheTrueColonel
      Junior Member
      • Nov 2024
      • 5

      #32
      Why are y'all still so up in arms about this? Arch only officially supports x86_64. The AUR is focused on Arch. There shouldn't be an expectation of the AUR to allow anything other than what would work on officially supported architectures.

      While it would be nice for them to allow things not supporting x86_64, they don't have to allow packages for third-party distros or any other unofficial builds.

      Comment

      • dlq84
        Senior Member
        • Jul 2012
        • 434

        #33
        You could argue that Arch should support Arm officially, but that's not the case. Therefor it doesn't make sense for AUR to host Arm-only stuff. Surely there is a AUR equivalent for Arm somewhere?

        Comment

        • skeevy420
          Senior Member
          • May 2017
          • 8660

          #34
          Originally posted by schmidtbag View Post
          I'm aware, but why should these other distros have their own AUR when they can just make a repo?
          The same reason that Arch has the AUR -- their devs don't want to maintain some random package that some random person wants.

          The AUR exists out of convenience, not necessity. If more people contribute, it generally becomes better.
          It exists for the convenience of Arch Linux and all the reasons you're about to go into. It just happens to be convenient to use for Arch-based distributions.

          I would argue the AUR as it is already qualifies as that - the whole point of the AUR is an easy source of 3rd party software that the Arch maintainers aren't held responsible for maintaining. There's a lot of crap packages on the AUR and even stuff that may be legally questionable, but that's not the Arch dev's problem. So, why should it matter if there are other architectures on there?
          Because the distribution itself doesn't support those architectures. That's why. There is no greater reason.

          I really don't see why those are the only options. pkgbuild files have always had a line for architecture so if the main Arch devs were so keen on excluding non-x86-64 then they'd remove that as a field. Again: the whole point of the AUR is to absolve the main Arch devs of responsibility.
          "Oh, you bricked your system because you installed a kernel from the AUR? Not my problem"
          "You got ransomware when you installed that sketchy AUR package? Sucks to be you"
          "The package won't build correctly? Contact the maintainer, not me"
          All of these are valid things Arch maintainers/devs can say in response to bad AUR packages. These are things that can happen from AUR packages built for vanilla Arch on x86-64 CPUs. Look at the home page for the AUR:
          "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk."

          So, you have a resource with known bad packages for the original distro and there's not always an obvious way of knowing this, but somehow installing a package obviously meant for another architecture is polluting the system, when all it takes is a single field to filter such packages?
          I'm sure there are other options, but staying as-is leads to this argument here where you're going "Just because it can do it means that it should." and I'm going "Just because it can do it doesn't mean that it should."

          This is one of the rare situations where you can have your cake and eat it too. I don't think having a filter for architecture is too much to ask and it's definitely not some gateway into adding responsibility to the core devs. ALARM has been a 3rd party project and always will be; I don't see how filtering the AUR would change this.
          No, it's not . . . and I'm a bigger guy that just bought some cake flour. So what that they have a filter that can distinguish between source, no arch, binary, etc or that the filter can be expanded? They're allowed to limit their platform to the formats that they support.

          EDIT:
          In the AUR search, imagine if the "out of date" filter field was missing. Suddenly, it gets to be a lot harder to identify AUR packages that are properly maintained or still relevant. It's hardly adding any complexity but it makes an immense difference in finding what you actually want. Since the AUR is designed for vanilla Arch, they can have the architecture field default to "x86-64" (which would also identify packages that work for all architectures).
          The fuck? Imagine La La Land making things harder is what you're going with? I tried Imagination. It lead to a cooperative where various Arch-based distributions could come together and solve this problem instead of forcing Arch to solve their moocher problem. To me, ALARM, CachyOS, Manjaro, ALHP, all the Arch-based distributions -- they all might as well be some form of Rocky Alma Mooch if they're willing to dump their AUR issues onto Arch; to let Arch just add some fields here and there to accommodate Not Arch.
          Last edited by skeevy420; 08 January 2025, 02:14 PM.

          Comment

          • schmidtbag
            Senior Member
            • Dec 2010
            • 6618

            #35
            Originally posted by skeevy420 View Post
            The same reason that Arch has the AUR -- their devs don't want to maintain some random package that some random person wants.
            Right... so the other flavored distros provide their own one-off repo. They can still use the main Arch repos if they want, while also providing one of their own.
            It's not unheard of for a distro to use another distro's repos but they have additional repos of their own.
            Because the distribution itself doesn't support those architectures. That's why. There is no greater reason.
            Then why have the architecture option? What's stopping them from getting rid of it from pkgbuild if vanilla Arch is so determined to be x86-64 only?
            I'm sure there are other options, but staying as-is leads to this argument here where you're going "Just because it can do it means that it should." and I'm going "Just because it can do it doesn't mean that it should."
            There is more to gain by allowing other Arch-derived distros to participate in the AUR than it is to isolate them over something that could be implemented in a matter of minutes. That would be like excluding 18-wheelers from using roads because some of them are too tall to fit under some bridges, when all they need is just an update to their GPS to take them on a compatible route. The amount a society gains from such trucks is greater than what it loses from them occasionally slamming into a short bridge.
            No, it's not . . . and I'm a bigger guy that just bought some cake flour. So what that they have a filter that can distinguish between source, no arch, binary, etc or that the filter can be expanded? They're allowed to limit their platform to the formats that they support.
            Who said anything about being allowed? I'm saying they lose nothing by just allowing people to filter the architecture they actually use.
            Also, how hard do you think it is to check a text file? Because that's what a pkgbuild is. It has a dedicated section for architecture:

            They even mention armv7 and aarch64 ffs... This is the official wiki, not the ALARM one.
            Again - what's the point of keeping it if the core devs have no intention on using anything but x86-64?
            The fuck? Imagine La La Land making things harder is what you're going with? I tried Imagination. It lead to a cooperative where various Arch-based distributions could come together and solve this problem instead of forcing Arch to solve their moocher problem. To me, ALARM, CachyOS, Manjaro, ALHP, all the Arch-based distributions -- they all might as well be some form of Rocky Alma Mooch if they're willing to dump their AUR issues onto Arch; to let Arch just add some fields here and there to accommodate Not Arch.
            In my original post, my initial question of "how many of these confusing ARM packages are there?" wasn't entirely rhetorical. How prevalent do you think this is? How many MEGAbytes do you think are used on these moochers? How much of these non-vanilla AUR contributions do you think aren't relevant to vanilla Arch users?
            Your imagination is lacking. I thought you were more reasonable than this.
            Last edited by schmidtbag; 08 January 2025, 03:17 PM.

            Comment

            • NekkoDroid
              Junior Member
              • Feb 2024
              • 43

              #36
              Originally posted by schmidtbag View Post
              They even mention armv7 and aarch64 ffs... This is the official wiki, not the ALARM one.
              Again - what's the point of keeping it if the core devs have no intention on using anything but x86-64?
              To answer this: they don't have a problem with PKGBUILDs supporting other arches *in conjunction with* x86-64. They have a problem with PKGBUILDs that can't be installed/built for the only supported platform.

              In other words:
              HTML Code:
              # OK
              arch=('any')
              # OK
              arch=('x86_64' 'armv7')
              # Not OK
              arch=('armv7')

              Comment

              • schmidtbag
                Senior Member
                • Dec 2010
                • 6618

                #37
                Originally posted by NekkoDroid View Post
                To answer this: they don't have a problem with PKGBUILDs supporting other arches *in conjunction with* x86-64. They have a problem with PKGBUILDs that can't be installed/built for the only supported platform.
                Fair enough, but again I have to ask: how much of a problem are packages incompatible with x86-64? Given the FEX example in the article: why would any x86-64 user want to install that? Seems like a rather strong reaction to something that has little to no impact on x86-64 users at all.

                What I think is perfectly fair to remove are packages that needlessly exclude x86-64 support even if it would run fine on that anyway. Part of me wonders if any of such packages even exist.

                Comment

                • loganj
                  Senior Member
                  • Nov 2017
                  • 608

                  #38
                  but is it possible to build arm package on x86? if so they could allow the aur to build the package but don't allow to install it on x86.
                  well i actually like this decision. it makes sense considering that the officially arch is for x86-64 only.

                  Comment

                  • Mr.Elendig
                    Junior Member
                    • Jun 2010
                    • 47

                    #39
                    Originally posted by loganj View Post
                    but is it possible to build arm package on x86? if so they could allow the aur to build the package but don't allow to install it on x86.
                    well i actually like this decision. it makes sense considering that the officially arch is for x86-64 only.
                    AUR is only a repository of build scripts etc, it is not a build service.

                    Comment

                    • Quackdoc
                      Senior Member
                      • Oct 2020
                      • 5072

                      #40
                      Originally posted by loganj View Post
                      but is it possible to build arm package on x86? if so they could allow the aur to build the package but don't allow to install it on x86.
                      well i actually like this decision. it makes sense considering that the officially arch is for x86-64 only.
                      no, sadly if you want to cross compile you need to use distcc. I wish it did though, cross compiling for arm or riscv is a pain.

                      Comment

                      Working...
                      X