Searching for an improved AUR manager.
Searching for an improved AUR manager.
The AUR offers great features but lacks consistent management. I’ve discussed how bloated AUR managers can become. However, I have some questions before continuing. I noticed not every package needs compilation—some come with a ready-to-install binary. I also discovered a small but bothersome issue. There’s a browser called Thorium, a fast Chromium fork, listed on the AUR as "thorium-browser-bin." In reality, it supports AVX, AVX2, and SSE3. When I install it using yay, it always selects the SSE3 version (a .deb file on Arch). Using auracle, a git clone downloader, it fetches multiple PKGBUILD files for different architectures. Just run makepkg -si on the chosen file and it installs it. Installing packages seems straightforward, yet the bloat remains. I still have source code, dependencies, and extra overhead. If installation is easy, what’s the point of skipping an AUR helper altogether? Then I’d have to manually search the AUR for each package. Is there a more efficient, automated method? Probably what I’m after is cleaning up after installation. As mentioned earlier, I don’t mind the generated source files and want to remove all dependencies completely. What would be the most reliable way to do this? Finally, I’m wondering if a different helper might suit me better. Yay runs in Go, which adds its own weight (though manageable). I’ve used auracle, but it only clones repositories without building them. On the Arch Wiki https://wiki.archlinux.org/title/AUR_helpers, what do you think—using a Pacman wrapper or building helpers yourself?
Now it's your turn to create your own Linux setup. You'll notice a lot of unnecessary features. Define clear boundaries for what counts as bloat and adapt accordingly. I switch distros regularly just like everyone else until I discover the ideal one. You might have to settle for what you have or keep moving forward.
Since it duplicates the repository unchanged and executes makepkg against the standard target, which is the default PKGBUILD. If you wish to use a different PKGBUILD, specify "--mflags" with the desired path. Of course, updates will try to apply the default PKGBUILD. As a Pacman wrapper, it respects Pacman's ignorepkg settings in "/etc/pacman.conf". IgnorePkg = podman-desktop will produce a message similar to the one shown when running "yay -Syu" during an update: "podman-desktop: ignoring package upgrade (1.9.1-1 => 1.10.0-1)". It's common for bin PKGBUILDs to include packages from other distributions. The proper approach is to locate a suitable AUR package, such as thorium-browser-bin, and clone it directly. Make sure your yay configuration includes "removemake" to eliminate make dependencies after installation. You can clear the cache with "yay -Scc --aur --noconfirm".
If yes, I can handle it using a bit of bash scripting. Using a helper makes it easier to search for packages on the AUR. How would you run a recursive search in the AUR mirror? Once you lock onto a package, you can clone it with git and execute the makepackkg command. Updating packages is also something you should consider implementing. This approach lets you build your own AUR helper. I’d like to try other helpers as well.
Fetch the Thorium repository using curl and jq. The URL path reflects the latest snapshot from pkgbuild. You can download the tarball directly or clone the repository via git. For details on the RPC interface, refer to the Arch Linux Wiki entries provided.
It's not only simple—it's the only officially recommended method. Just check the wiki page. https://wiki.archlinux.org/title/Arch_User_Repository Specifying build flags can be handled in /etc/makepkg.conf no matter which aur manager you're using (if any). That doesn't mean bloat is acceptable under any interpretation. If your disk sources cause issues, remove them. If you don't require the build dependencies, uninstall them afterward. By the way, we'll ask if you'd like them removed automatically. If you prefer not to let it happen, do it manually as the arch developers intended.
I’m really frustrated right now. Even after downloading just the binary, there’s still a lot happening—like handling fakeroot, compressing images, and more. Installing the binary from the original source is much faster and produces almost no extra files. Even when I just install the kernel with yay, it does way too much instead of just installing the kernel itself. The Pacman method is so much cleaner. I’m furious because I just tried to install the otf-fira-code package, which is supposed to be a font. It took a huge amount of time and many dependencies to compile, and it ended up using gigabytes of space. I don’t even use the AUR anymore. This AUR experience is getting worse by the day.
because it starts from the ground up and relies on external components. Checking the pkgbuild dependencies reveals some AUR Python modules that need their own builds. If this frustrates you, opt for a pre-built version—but be prepared to settle for a less complex setup if you don’t want to deal with those intricacies. The benefit of using the AUR is the broad selection of packages available, something you’d otherwise have to assemble yourself. If you’re not interested in that level of complexity, there are other options to consider.
Understand how AUR and PKGBUILD function together. Take otf-fira-code-git, which fetches code from GitHub and runs a build script. This script depends on several AUR packages like gftools, git, python-compreffor, etc., each of which must be compiled manually. You're not just installing a font; you're assembling it from source. AUR packages are built for Arch Linux, so they need proper packaging and tracking. Issues can arise if dependencies aren't in sync or if the build order is incorrect. The process often involves manual steps to ensure everything compiles correctly.
@Nayr438 Thanks for clarifying how the AUR functions. Still, if I’m not making any mistakes, this method remains quite unstable, particularly for simple things like fonts. I’d use it only if I’m compiling from source myself, which is my approach, but I lack sufficient computing power to ensure reliability. I wasn’t sure what a font actually is—I initially thought maybe image files were involved, though that was just a rough idea. Probably when you work with vectors, geometry, ligatures, etc., it turns into something you must compile according to your system’s settings. But if I can obtain the same result as a binary version without much effort or trade-offs, then why would I bother compiling it unless there’s a specific reason?