So I’ve been iso live testing Manjaro KDE Plasma lately and it looks very polished.
On the other hand, there is a negative vibe towards it.
Why the hate?
So I’ve been iso live testing Manjaro KDE Plasma lately and it looks very polished.
On the other hand, there is a negative vibe towards it.
Why the hate?
The AUR doesn’t assume arch packages, if the package your aur script wants isn’t in your repo then the package simply fails to update/install.
Edit: This is true even for Arch linux, as the Aur package might be out of date.
There are many cases where Manjaro causes problems. For example, a package mag already be in Arch but not yet in Manjaro. Or perhaps the Manjaro package is not a high enough version number. If another Arch package requires this first package, in Arch it would grab the Arch package. The Arch package will be maintained over time. In Manajaro, the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number. Over time, the AUR dependency breaks or becomes unmaintained. Even once Manjaro has the package, it may not migrate it because of the version numbers. Now things are broken. This exact thing happened to me on Manjaro where my GIMP ended up using GEGL from the AUR. My system was broken for months.
An even worse problem can happen when there are alternate dependencies. Sometimes in the AUR you will have multiple packages that fulfill a dependency. In Arch, you can see if one is from the actual repos and one is itself from the AUR. Again, if you choose the one in the repos, it will work and stay supports. In Manjaro, neither may be coming from the actual repos in which case it is easy to choose the wrong one. This sets you up to have package conflicts. In Manjaro, I would never know that the other option had now been added to the repos. More than once, I had the dependency that I had chosen break when the other would still have been fine.
Ok, this is getting long and that was just a couple of scenarios.
Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.
That’s not how source packages work. The only way they’d break is in case of major upstream changes. Which do happen, but the only inconvenience would be recompiling the package. Which you’re supposed to do anyway.
Do you reinstall your AUR packages after an update? If yes, you will never see them break on Manjaro or Arch. If you don’t, they will break on both Manjaro and Arch.
I am not theorizing. And I am not taking about source code not compiling. I am talking about dependencies which includes the reports version numbers and version number expectations of packages maintained by different parties. Those broke all the time for me on Manjaro and it was often because of the differences between what was in the Arch repos vs the Manjaro repos.
When Manjaro fell behind at one point, I ended up with a version of GEGL ( labeled - git ) being pulled from the AUR. Later releases of GIMP refused to upgrade over that version of GEGL. I just lived with it for a few months hoping it would clear itself up but it never did. I basically had to back everything my out and install again. Not that it was hard but these kinds of annoyances happened for me all the time on Mnajaro and basically never on EbdeavourOS or Arch.
What made me move away from Manjaro to begin with were all the problems it had with the dotnet packages at the time. I blamed dotnet and the AUR and was amazed that the problems went away when I used EndeavourOS instead.
If what you describe were true it would make AUR packages fail (on any Arch distro) if the user failed to upgrade their system each time, every time an update came out. The two week delay practiced by Manjaro is a completely arbitrary period of timen in the grand scheme of things. There are users who only upgrade once a month or even more seldom and nothing like this happens to them.