On Archlinux it is not recommended to update only one package with the package manager pacman. Let’s say I have 11 packages, and one of them is extra/firefox (true story). Updating only a pacman -S firefox could introduce problems, but installing a new single package if it wasn’t there is okay.

So my question is, could we get around this by removing and installing the same package again in one go: pacman -Rs firefox && pacman -S firefox

  • frongt@lemmy.zip
    link
    fedilink
    arrow-up
    0
    ·
    2 days ago

    I’m not familiar with arch or pacman. What prevents a package from becoming too new? Like if a new version of libssl is released that removes a necessary function but a package like Firefox has become abandoned, then even updating everything will result in a broken application. Does it not have version dependencies like debs and rpms?

    • Crestwave@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      2 days ago

      Adding on to what the other commenter mentioned, that is called a breaking change and would generally be avoided at all costs by libssl. See, e.g., the decades-long python3 transition.

    • kevincox@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      2 days ago

      I’m also not familiar. But my understanding is that the package maintainers should prevent this situation. Because otherwise even if there are package version dependencies (I don’t actually know if pacman does this) it would just block the update which results in a partial update which isn’t supported. For example if your theoretical unmaintained Firefox blocks the update of libssl but Python requires new functionality you would be stuck in dependency hell. Leaving this problem to the users just makes this problem worse. So the package maintainers need to sort something out.

      It is a huge pain when it happens but tends to be pretty rare in practice. Typically they can just wait for software to update or ship a small patch to fix it. But in the worst case you need to maintain two versions of the common dependency. In lots of distros very common dependencies tend to get different packages for different major version for this reason. For example libfoo1 and libfoo2. Then there can be a period where both are supported while packages slowly move from one to the other.

      • frongt@lemmy.zip
        link
        fedilink
        arrow-up
        0
        ·
        2 days ago

        If a package manager can block an upgrade due to version dependencies, it can also pull in those dependencies for a partial upgrade.

        • chakli@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          2 days ago

          If a function is removed from libssl and it’s used in firefox, firefox build would fail, so it’s still not possible to have a functional setup.

          • ulterno@programming.dev
            link
            fedilink
            English
            arrow-up
            0
            ·
            1 day ago

            Yeah, that kind of a condition would require the maintainer to patch the source of the non-updated program.
            And that would be fine if there is just a little change, with an alternate function available but if the change requires changing the logic of the application, you are essentially expecting the package maintainer to do the software developer’s work.

            The deprecation process is a good way to prevent this.