Manjaro 2.0 Synopsis This document covers the organizational, technical, management, and other changes we (the Manjaro Team, et al) like to see applied to the Manjaro Project. The goal of this document is to serve as a point of discussion, and ultimately, once a consensus on its contents and written goals has been reached, as a guide for the organizational restructuring of the Manjaro Project. Motivation The Manjaro Project has been declining over the past decade. It managed to sustain a sizabl...
Interesting. As a former Manjaro user (several years ago now), my problems with the distro were more with their approach to package management and the AUR. They withhold packages for the main repositories, but the dependencies for AUR packages will always assume the latest packages, so I would constantly get into these dependency deadlocks where I could not install or could not update certain AUR packages because the necessary dependencies were the incorrect version. I view this as a fundamental technical problem with their approach, and was my main reason for switching away.
Hopefully the new structure/leadership will result in technical changes which fix their issues. Though if I am being honest, the vision of a Manjaro with rolling packages is basically just a reskinned EndeavourOS, so I am not sure what they would need to do for me to recommend this distro to anyone.
This was exactly the same for me. Every Manjaro install I had broke sooner or later because of these dependency issues. After my 3rd or 4th try, I decided to switch to EndeavorOS which is extremely stable for me and serves me well for a couple of years now.
I’ve used Manjaro and, over time, it’s left me without GRUB and without a graphical interface on several occasions – just as has happened with CachyOS, EndeavourOS, Arcolinux, and others. That’s why I no longer use Arch or Arch-based distributions. I admit that, in my opinion, Manjaro is the best Arch-based distribution, provided you don’t install anything from the AUR repository. The problem is that Pamac and some of Manjaro’s own tools don’t follow Arch’s dependency rules, so that mix of Manjaro’s own repositories and Arch’s original repositories can be a problem.
I just avoid the AUR on Manjaro whenever possible. It still works 99% of the time. The few things I actually need to be bleeding edge I will just try to build from source.
IMO they should have made this the official policy instead of adding optional support for the AUR in pamac.
At the end of the day, the AUR is just a pastebin full of pkgbuild files for people who know what they’re doing. And as a distro aimed more at the average Linux user, rawdogging the AUR probably just shouldn’t be part of the equation.
It optional, for power users. That the point.
Everything is always optional for power users on linux. What I’m saying is they shouldn’t have made a GUI checkbox that’s also easy enough for non power users to check.
So power users can’t use GUI?
The dependency issues seem like that are a flaw in the Arch design. It is the only package manager I’ve seen that requires running the latest available version of packages.
Why should that be a flaw on Arch’s side, when it ooses no issue on Arch’s side? Partial updates are explicitly not supported. That would be fine for Manjaro if they would not encourage the use or for some cases even enable the use of AUR by default.
This is what I’m referring to. Pacman is the only package manager I’ve used with this limitation.
Yes but that is on Manjaro if they do not follow basic rules from their upstream and not on arch. If you ignore design desicions then thats on you.
True, but also why is that a rule from upstream?
Thats the only (sane without tons of work) way how you can have a rolling release distro without the need to compile everything yourself, everytime. Dependency issues will occure when glibc gets updated (or any other library) and you only update some programms but not all, its possible that those programms work or not.