Dne 30. 06. 23 v 10:34 Benson Muite napsal(a): There is a catch. Packages which are FTBFS cannot be marked as deprecated, because there is no way to inject the `Provides: deprecated()` there without the build. Vít

On 6/30/23 04:34, Benson Muite wrote: There are other valid reasons to deprecate packages. Upstream deprecation is one of them. For example, three of the subpackages in python-opentelemetry are currently deprecated because upstream has deprecated them, and I expect them to disappear in the future. Deprecating the subpackages keeps anyone from packaging something that depends on them and then being impacted a few months later by their removal in Rawhide. In my experience, deprecation is used extremely sparingly (there are only 42 spec files in the entire distribution with the string “deprecated()”), and I am not aware of any issues with it being used carelessly. Furthermore, the current policy already requires a FESCo-approved change to deprecate anything that has dependent packages. I am not convinced that the proposed Change clearly or accurately reflects all of the valid uses for deprecation, nor am I convinced that attempting to codify these uses is useful to packagers or solves an actual problem in the distribution or community. There certainly is no extant policy on how much upstream activity a package needs to have to enter or remain in Fedora, nor do I think it is reasonable to regulate this on anything other than a case-by-case basis. There are decades-old scientific tools with deceased authors that are still perfectly useful, there are tools that are “done” but have upstreams that spring into action after ten years of quiescence if a new bug is found, there are network libraries with large attack surfaces that might cause concern if an upstream PR or issue languishes untriaged for a few months, and there is everything in between. The document https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to... already warns about the added maintenance burden of packaging projects with inactive or absent upstreams, and it is reasonable for a package reviewer to warn the submitter about an inactive upstream. It still makes sense to package these projects when they are sufficiently useful or when good alternatives are not yet available.

Ben Beasley wrote: IMHO, it is not. Packages that are not actively maintained upstream tend to be very little maintenance effort in Fedora, because there are no new upstream releases to pick up. You just need to keep the package compiling and address security issues. Sure, there are packages where either or both of these is impractical, in which case the package should just get orphaned and eventually retired. But planning for the package removal before this is even an issue, just because upstream deprecated the package, does not make sense. It can prevent useful software from entering Fedora just due to the upstream maintenance state of a single (possibly even transitive) dependency, whose impending removal from Fedora is entirely unnecessary. And I am speaking from experience there, as one of the people keeping the Qt/kdelibs 3 and 4 stacks working for legacy applications to use. Those are a lot less work to maintain than the current KDE Frameworks that need to be updated to a new upstream release every month or so. Kevin Kofler