If Manjaro does have its own regular repos why can’t it have its own AUR repo ? Because most critics target the danger of synchronizing between Manjaro repos and the current used AUR that’s synched with Arch repos. Manjaro with its stable branch is the optimum solution to tackle lack of stability in any Arch based distro. The only remaining problem is the usability of Arch AUR inside Manjaro which is not good, we really need an alternative to it because AUR has huge list of apps that are much needed by many users.
The AUR is neither officially supported by Arch nor Manjaro. If you do use the AUR on Manjaro, use our unstable branch. Problem solved.
Tip: The AUR is not a package repository, it’s a collection of package recipes created by users.
AUR provides an easy/fast way to install many useful apps, and I don’t know if any Manjaro user who doesn’t use it, so to minimize its importance and label it as not supported is not just. The problem is that AUR apps dependencies are created and updated in synchronization with Arch repos, so any attempt to enable it on Manjaro will create a gap of synchronization between it and Manjaro repos, what I’m asking if there’s any way to create a stable snapshot of AUR that match each Manjaro stable update ?
If I use unstable branch, I would prefer to go directly with Arch, but I’m loving the stable branch and how it provides the balance between stability and new updates.
There are currently 83,967 AUR packages. Find someone to moderate every single one, then we’ll talk.
There are hundreds of thousands of Manjaro users. Most use the stable branch and do not use the AUR. We see a very small percentage of them here on the forum.
There’s a saying: “You can’t have your cake and eat it, too”.
No. There’s no synchronization whatsoever. We AUR package authors, create AUR packages based on what we know working on our own system. All of my packages are made on my Manjaro system, I don’t have Arch installed elsewhere and my packages could break anytime on any system due to dependencies update. This is just the nature of AUR.
When one creates a PKGBUILD for any application - the build script will reflect the use on the system it is created for. The vast content within AUR has been created by an Arch user and for Arch Linux usage.
For as long as the version of any given dependency is available with your primary mirror there will be no issues.
A very simplified representation
As you can see from this Manjaro may have up to 3 different versions of any dependency - depending on the branch. Any PKGBUILD will usually specificy a dependency by name - which allows for any version of the dependency to be used.
BUT - two versions may not be identical - e.g. bugfix or change in function - in which case the PKGBUILD will build a dysfunctional app if the available version is v2 but a bugfix has been implemented in v3 and v4 is an improved version.
The resulting app will behave differently depending on the branch you are connected to.
AUR is a user repository - the ‘Arch User’ repo can house applications specifically intended for Manjaro, Garuda, or any other distribution based on Arch.
You are doing what many people tend to do, to discuss hypothetical issues. Whilst it’s true that many AUR packages do get updated to catch up with Arch, it doesn’t cause me any personal issues.
Hmmm think of a REAL CASE here or it’s useless…
kwin-effects would be a good one. Before Manjaro updated from 5.25 to 5.26 I updated this package, and it obviously wouldn’t work with 5.25 any more - so I had to simply remove it.
So now, I just take a bit more care with updates - run Pacman -Syu instead of pamac update or use an update menu to review options.
I can only think of that one particular example TBH, the issue being bleeding edge plasma development - the only other item that failed me was an OSD clock which was simply unmaintained anyway and is now gone.
yay --upgrademenu --combinedupgrade -Syu
The only synchronisation between an AUR package with the rest of the OS is done by the user who builds it.
If the OS upgrades the user has to rebuild the AUR packages.
Or if the OS is behind the requirements of an AUR package the user has to wait with building the new version of an AUR package.