On 6/30/23 17:05, Ben Beasley wrote:
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.
Deprecation due to upstream deprecation is reasonable. Would be great
to have this in such a policy.
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.
Aspell was recently deprecated due to lack of recent activity upstream.
It would be good to have guidance for deprecation vs. orphaning. The
deprecation process does provide advance notice of an action which
orphaning does not. Advance notice is good to have where possible for
packages with many dependencies or a wide user base.
> 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.
Essential crypto libraries
have greater review.
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.
The recommendations made are reasonable.