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...
  • Giloron@programming.dev
    13·
    21 hours ago

    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.

    • ShortN0te@lemmy.ml
      3·
      17 hours ago

      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.

      • Giloron@programming.dev
        11·
        3 hours ago

        Partial updates are explicitly not supported.

        This is what I’m referring to. Pacman is the only package manager I’ve used with this limitation.

        • ShortN0te@lemmy.ml
          1·
          3 hours ago

          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.

            • ShortN0te@lemmy.ml
              2·
              53 minutes ago

              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.