On 6/30/23 04:34, Benson Muite wrote:
There is at present no policy on when and why packages should be
deprecated. Have made a proposal to allow deprecation of packages only
when they fail to build or are a security concern. In other cases,
orphaning and retirement should be done. Comments and suggestions for
improvement are welcome.
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.
This would also likely impact package review guidelines, since there
are
packages that people may want in Fedora, which build but do not have
much upstream activity.
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.