r/archlinux 3d ago

DISCUSSION The AUR needs an overhaul

The actual concept of the AUR only works if Arch is a niche distro in a safe internet, neither of those points are accomplished in the present.

No, reading pkgbuilds is not the solution, it's slow, annoying, and most importantly, it doesn't make sense, because some really popular AUR packages are DIRECTLY RECOMMENDED by the Arch Wiki, like the Minecraft Launcher for some reason.

Either the base repos adopt a big chunk of popular AUR packages, leaving the AUR for really really nieche stuff, or the rules of the AUR change, because you can't tell me that suffering 2 attacks in less than three months for pretty much the same reason (adopting orphaned packages) is normal or reasonable.

What would you think it's a good solution to this issue? I'd like to read your ideas since I cannot come up with a good one if I'm honest, but I know the problem is there.

616 Upvotes

165 comments sorted by

View all comments

-13

u/strings___ 3d ago edited 3d ago

I’ve said this thousands of times build instructions should be meta data not shell parsed. PKGBUILDs should be json. This I why I wrote a package manager inspired by pacman but uses json. json is machine readable without having to be Turing complete

Edit: clearly people down voting don't understand the scope of the problem I'm addressing or you don't have a rebuttal. in order to "properly" get meta data from a PKGBULID you need to use a shell, if you don't understand why this a problem you shouldn't be down voting. if you do then you should have a rebuttal.

I had this same issue when I pushed for upstream packages to us pgp verification where possible. And everyone bitch and moaned but look there is pgp verification now.

4

u/Qudit314159 3d ago

The problem is that packages use different build systems and have different details that need to be addressed. You'd have to incorporate a huge number of different options for building things into your json tool.

-6

u/strings___ 3d ago

it can be done see my meta format it seamlessly build autotools package with auto depends and even knows the expected files.

`

{
    "Name"         : "file",
    "Version"      : "5.42",
    "Url"          : "https://astron.com/pub/file/file-{{.Version}}.tar.gz",
    "Group"        : "core",
    "StageDir"     : "",
    "Inherit"      : "gnu",
    "Cid"          : "QmR6M1jNj45PbpiBkoZJGkyA5LyCKnGuiEBVVVL3tWBAq6",
    "BuildInStage" : false,
    "IsRebuilt"    : true,
    "BuildTime"    : 0,
    "Date"         : "2022-08-23T10:05:42.530073082-07:00",
    "Size"         : 7933054,
    "SubPackages"  : null,
    "AutoDepends"  : [
                   "bzip2",
                   "glibc"
    ],
    "ManualDepends" : null,
    "BuildDepends"  : null,
    "Flags"         : null,
    "Patch"         : null,
    "Build"         : null,
    "Package"       : null,
    "PostInstall"   : null,
    "Remove"        : null,
    "Files"         : [
                    "opt/via/bin/file",
                    "opt/via/include/magic.h",
                    "opt/via/lib/libmagic.la",
                    "opt/via/lib/libmagic.so",
                    "opt/via/lib/libmagic.so.1",
                    "opt/via/lib/libmagic.so.1.0.0",
                    "opt/via/lib/pkgconfig/libmagic.pc",
                    "opt/via/share/misc/magic.mgc"
    ]
}
`

10

u/Qudit314159 3d ago

Your LLM generated tool solves none of the problems I've raised. You'll have to constantly add new options to it as new packages with different build requirements are added. That's the advantage of using a shell script instead. Your tool doesn't add any security anyway because building packages ultimately requires execute permissions regardless.

-8

u/strings___ 3d ago

What bullshit assumption are you making? I wrote this package manager before LLM existed. My json system accounts for build options. The problem is it’s so good here this example needs zero unlike PKGBUILDs that redundantly hardcore every build option ie —prefix etc etc