Announcement

Collapse
No announcement yet.

Fedora Developers Are Looking At Better Managing Retired Packages

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora Developers Are Looking At Better Managing Retired Packages

    Phoronix: Fedora Developers Are Looking At Better Managing Retired Packages

    A change proposal for Fedora 33 would introduce the concept of "fedora-retired-packages" for removing retired packages when upgrading Fedora...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So deb autoremoval reinvented 20 years later?

    Comment


    • #3
      This has nothing to do with Debian's autoremoval, which only removes packages no longer required by any dependency but not manually installed ones.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Originally posted by carewolf View Post
        So deb autoremoval [...]?
        No, that's `dnf autoremove` (or in the past `yum autoremove`)

        I think Michael pretty clearly explained this is about user-installed packages that are no longer packaged. (e.g., no maintainer, upstream disappears, upstream unmaintained, legal reasons, ...)

        Comment


        • #5
          Originally posted by johnp117 View Post
          No, that's `dnf autoremove` (or in the past `yum autoremove`)

          I think Michael pretty clearly explained this is about user-installed packages that are no longer packaged. (e.g., no maintainer, upstream disappears, upstream unmaintained, legal reasons, ...)
          Yeah, but that would be autoremoved. It is how old kernels are removed (can't just be upgraded as you need to keep the old and new version in parallel until rebooting)

          Comment


          • #6
            Originally posted by carewolf View Post

            Yeah, but that would be autoremoved. It is how old kernels are removed (can't just be upgraded as you need to keep the old and new version in parallel until rebooting)
            No, old kernels are removed in dnf because they are handled separately

            https://dnf.readthedocs.io/en/latest...ly-limit-label

            If a random package that user happen to be installed got retired by the distribution, they would just stay installed. Autoremove has nothing to do with that at all

            Comment


            • #7
              Originally posted by carewolf View Post
              Yeah, but that would be autoremoved.
              Are you saying `apt autoremove` removes user-installed packages that do not appear in the repositories any more? IIRC it doesn't do that and the man page contradicts you as well:

              Originally posted by apt(8)
              autoremove is used to remove packages that were automatically installed to satisfy dependencies for other packages and are now no longer needed as dependencies changed or the package(s) needing them were removed in the meantime.

              Comment


              • #8
                Don't get confused with RETIRED vs. ORPHANED packages.
                Every 2nd week someone on the fedora devel list announces hundrets of packages that got orphanded because the maintainers left the building.
                The lists are usually so long, that no one really scans them besides a handful of people.
                The question that solves the "retired" packages problem should be: Why do people leave Fedora ? Maybe some structural issues, envisioning or paths that some core developers suggests have stirred up the maintainers of these packages and so they left.

                Comment


                • #9
                  Originally posted by Candy View Post
                  Don't get confused with RETIRED vs. ORPHANED packages.
                  The question that solves the "retired" packages problem should be: Why do people leave Fedora ? .
                  The most common (explicitly shared) reason seem to be ENOTIME. The packager has acquired sufficient additional responsibilities (in their life, in their org, ...) that their time for contribution to the Fedora community (for specific packages that no longer scratch one of their immediate itches) is no longer available. For some packages there is little to no effort, but there are a number of upstreams with constant churn, and the time to repackage (and test) is not always available, and the individual packagers see that not changing anytime soon, so they choose to let the package go (to either someone with more time, or someone with the itch to have it available).

                  The more interesting question would be how to get more individuals to participate in the community, and packaging. And Fedora has (re)started that conversation all over again (the discussions/efforts have happened before, and they will happen again).

                  Comment


                  • #10
                    Originally posted by CommunityMember View Post

                    The most common (explicitly shared) reason seem to be ENOTIME. The packager has acquired sufficient additional responsibilities (in their life, in their org, ...) that their time for contribution to the Fedora community (for specific packages that no longer scratch one of their immediate itches) is no longer available. For some packages there is little to no effort, but there are a number of upstreams with constant churn, and the time to repackage (and test) is not always available, and the individual packagers see that not changing anytime soon, so they choose to let the package go (to either someone with more time, or someone with the itch to have it available).

                    The more interesting question would be how to get more individuals to participate in the community, and packaging. And Fedora has (re)started that conversation all over again (the discussions/efforts have happened before, and they will happen again).
                    I actually think this touches on a larger issue that I've always wondered if it could be handled differently. Almost every distribution maintains their own copies of every package. It's a massive duplication of effort, time, and resources. In my head I can think of a ton of reasons why people will say it couldn't be done, but I think that a single massive package repository that all distributions could pull from would be great.

                    Comment

                    Working...
                    X