• Sims@lemmy.ml
    link
    fedilink
    English
    arrow-up
    5
    ·
    7 months ago

    Hm, I knew less about packaging than I thought. I kind of assumed it was mostly automatic updates after the initial package, and only fixing things on major changes.

    Anyway, looking at the different tables, it doesn’t seem to me that Guix is especially behind well known distros, and there’s a low percentage of problematic issues: https://repology.org/repositories/statistics/pvulnerable

    Perhaps it would be more telling to see how long packages are outdated on average? dunno…

    • LalSalaamComrade@lemmy.mlOP
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      7 months ago

      In the case of Guix, it’s just updating the version and the SHA-256 hash. But the bigger issue here is how hard GNU software is for contributions. I can’t do patches, because I do not want to jeopardize my email across the internet.

      • Sims@lemmy.ml
        link
        fedilink
        English
        arrow-up
        3
        ·
        7 months ago

        Hm, going slightly ot here. I wonder how long it will take before an ‘package maintainer’ AI is developed. Imho it won’t take long before we see the first semi-automated packager/pkg manager. I think we have all the open source parts, but not the agent network that does the actual work, yet.

        With a dedicated package agent, guix and any other smaller distro would be right behind the big ones.

        • LalSalaamComrade@lemmy.mlOP
          link
          fedilink
          English
          arrow-up
          3
          ·
          7 months ago

          Thanks for this comment, because it looks like this is a good point of discussion. I may be wrong here, as I’m not well-versed in Guile Scheme. Honestly, you don’t really need an “AI” for this. As a Nixpkgs contributor, I’ve come across a genius implementation by Ryan Mulligan. To explain this, I’ll use the example code at A packaging tutorial for Guix.

          You can see:

          (define-public hello
            (package
              ...
              (version "2.10")
              (source (origin
                ...
                (sha256 (base32
                  "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))
                ...
              ))
              ...
          ))
          

          Only the version and the base32 string have to be updated to get the next version.

          If you check a Nix expression (aka the code snippet that defines a package), it is similar to the Guile code snippet but Haskell-ish. The version variable stores the tag - it’s the same for both Guix and Nix. He’s made a bot, which will check if the tag is outdated, or not - using Webhooks, I think. Maybe Savannah projects do not support them, but other forges like GitHub, GitLab and Forgejo do. If they’re outdated, the bot will update both the SHA256 hash, as well as the version. And there you go, automatic package upgrade! Well, if the build fails, then welp, a human has to fix it. But the bot has managed most of the stuff auto-magically, so does resolving a few packages manually really matter?

          Btw, here’s the hard-working bot, r-ryantm.

  • highduc@lemmy.ml
    link
    fedilink
    arrow-up
    5
    ·
    7 months ago

    You mean packages? And the link is just the graph, no other information or anything 🥲

  • 82cb5abccd918e03
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    7 months ago

    TBF its not as big of a problem as you would think since most of the time (for BOTH the user and the maintainers) its as easy as changing the version and hash with a package variant and Guix will automatically recompile the new version.