Arch Linux keeps falling behind in package updates, basic packages like gdb and LLVM are newer in Fedora then in Arch, and Bash is newer in DEBIAN then in Arch. Why have package updates fallen so far behind?

  • Molecular0079@lemmy.world
    link
    fedilink
    arrow-up
    115
    ·
    1 year ago

    Those are packages that lot of other packages rely on and so as a result just needs more testing. Sometimes Arch is faster, sometimes other distros are faster. This is relatively normal.

    • Maxy@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      57
      ·
      1 year ago

      To add to this, all of the packages mentioned have a -git version in the AUR. The people who really need the absolute newest version can always install these packages. The rest of the people (those who prefer stability) can continue using a slightly older, but well-tested versions of these programs.

        • Thurstylark@lemm.ee
          link
          fedilink
          arrow-up
          37
          ·
          1 year ago

          The only way to get it stable is to work out the kinks before releasing it to your user base and breaking their stuff in the process.

          They’re a small group of volunteers. It’s amazing that they keep up as much as they already do.

        • rodneyck@lemmy.world
          link
          fedilink
          arrow-up
          15
          ·
          edit-2
          1 year ago

          No what you want is unstable Arch which you can freely do by changing the repos, but your user experience will be fraught with pain and issues. You can move to Debian and do the same by running their unstable branches, same results though, most likely a broken system.

          Both will get you the newest releases.

      • UnfortunateShort@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        And you can also install packages from the Arch testing repos - which I really wouldn’t want to - but it’s entirely up to you.

        I appreciate the work that goes into testing and patching stuff for Arch a lot. I don’t want my OS to break for no good reason. Getting an update a month earlier is no good reason.

    • djsaskdja@reddthat.com
      link
      fedilink
      arrow-up
      33
      ·
      1 year ago

      Wasn’t Python being behind the reason GNOME 44 took a little while to come out? It does seem like things move a little slower than they used to. Might be a good thing for stability in the long run. Think people need to be reminded that Arch is community run too. So updates might lag behind compared to these distros with big corporations behind them.

      • TableCoffee@lemmy.ca
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        1 year ago

        I believe I read there was only one package maintainer for Gnome on Arch, which is why the release took longer. We have to remember it’s often just regular people, or in that case, person, who maintains this stuff for free or very little. And just because upstream made a release doesn’t mean it’s a simple drop-in to our distro of choice.

  • Fryboyter@discuss.tchncs.de
    link
    fedilink
    arrow-up
    78
    ·
    1 year ago

    In general, I would like to note that a rolling distribution does not necessarily always have to offer the latest packages as soon as possible. Rolling primarily only means that updates are offered gradually via the same package sources.

    But this is just a general remark. :-)

  • restarossa@infosec.pub
    link
    fedilink
    arrow-up
    40
    ·
    1 year ago

    It does seem a bit slower than it used to, but it also seems more stable than it used to and I don’t think that’s a coincidence. These days I also see the occasional package pulled when it introduces issues which is not something I recall happening in earlier years. I think it’s great, personally.

  • UnfortunateShort@lemmy.world
    link
    fedilink
    arrow-up
    19
    ·
    1 year ago

    Worth noting that Arch just migrated to GitLab and changed its repo structure, while also deprecating Python 2.

    I’d imagine that took some folks some time

  • suspectum@lemmy.ml
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    OpenSUSE Tumbleweed is really good at keeping up with the latest packages while remaining really stable. Despite recieving gigabytes of updates since February when I first installed it I had a far better experience compared to the “stable” Ubuntu I was using before.

  • InverseParallax@lemmy.world
    link
    fedilink
    arrow-up
    10
    ·
    edit-2
    1 year ago

    All right, enough of this debian bashing, this isn’t 2007 anymore, they’re actually using up-to-date packages and kernels, you’ll need to find someone else to kick around now.

    I … liked… arch for a while, but they broke a few times (library dependency failure, think it was expat) and I’m not in this just for smug.

    Gentoo did the same, but probably going back to them as a hybrid distro, debian as the base, gentoo as the lxc working distro with some DE apps.

    Have a ton of cores, gentoo should be fun.

  • Spectacle8011@lemmy.comfysnug.space
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    I usually don’t mind when most packages get behind, but the one I always notice is GNOME. It’s been taking longer than I would generally expect for Arch to ship a new major update for GNOME. Fedora seems to have more up-to-date packages in most areas and ships them vanilla like Arch, as well as coming with a host of other sane defaults, so I’ve been thinking of making the switch…soon.

      • Spectacle8011@lemmy.comfysnug.space
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Oh, I didn’t know that! All I’ve ever seen when this question gets asked in the BBS is “it’ll be done when it’s done :)” which is fair enough. If they’re waiting for the .1 release as an indicator of stability, then that explains why it feels like a while.

  • mudamuda@geddit.social
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    To go x86_64-only was a mistake for Arch. Distros like Fedora or Debian, or openSUSE have universal building systems and infrastructure for building packages for different architectures. Arch just creates unnecessary fragmentation for the GNU/Linux landscape: software need to be packaged for the distro and for the same time PKGBUILDs cannot be reused in general for anything to go full Arch Linux. Not for other architectures, not for servers or LTS. Only for a x86_64 desktop niche. Arch Linux doesn’t scale.

    • Fryboyter@discuss.tchncs.de
      link
      fedilink
      arrow-up
      19
      ·
      edit-2
      1 year ago

      To go x86_64-only was a mistake for Arch.

      • The development team of Arch is comparatively small compared to other distributions.
      • To support platforms other than x86_64 one should have access to appropriate hardware to test the packages. I for one have not had i686 hardware for a while. This is probably true for many other users as well.

      Therefore, from my point of view, they have done everything right. Just like other, non-Arch based distributions, which are also now only offered for x86_64.

      Distros like Fedora or Debian, or openSUSE have universal building systems and infrastructure for building packages for different architectures.

      Right. And all have more collaborators and more money. For example, according to https://nm.debian.org/members/, nearly 1000 people participate in Debian.

      Arch’s core development team, on the other hand, consists of just 28 people without being paid for it. In addition, there are some “trusted users” (a bit more than 60 iirc) and some people responsible for support (wiki and IRC moderators etc.).

      Arch just creates unnecessary fragmentation for the GNU/Linux landscape: software need to be packaged for the distro and for the same time PKGBUILDs cannot be reused in general for anything to go full Arch Linux.

      Fragementation has always existed. Before Arch I had used Mandrake / Mandriva. With it I often could not use Redhat packages although they technically used the same format (RPM).

      By the way, in the case of Arch or distributions based on it, you can in many cases use PKBUILD files for other platforms as well. Often it is sufficient to modify the line arch=('x86_64') accordingly. I have done this in some cases where a software for Alarm (Arch Linux ARM) was not officially offered. I simply took the PKBGUILD file from Arch Linux and changed it accordingly. And yes, this does not always work.