On 2024-02-28 11:22, Florian Smeets wrote:
Dear ports community,
as the removal of ports is a recurring source of friction and dispute we
would
like to add a ports removal and deprecation policy to the porters handbook.
We tried to find a sensible middle ground between too fast removal and
keeping
unmaintained and abandoned upstream software in our ports tree forever.
When can or should ports be deprecated or removed?
This policy should give some guidance on when ports can or should be
removed. In
general ports should not be removed without reason but if a port blocks
progress
it should be deprecated and subsequently removed. In general, if a ports
blocks
progress for some time it will be removed so that progress can be made. For
more
details see below.
Ports can be removed immediately if one of the following conditions is met:
- Upstream distfile is no longer available from the original source/mirror
(Our
and other distcaches e.g. Debian, Gentoo, etc do not count as "available")
- Upstream WWW is unavailable: deprecate, remove after 3 months
- BROKEN for more than 6 months
- has known vulnerabilities that weren’t addressed in the ports tree for
more than 3 months
A port can be deprecated and subsequently removed if:
- Upstream declared the version EOL or officially stopped development.
DEPRECATED
should be set as soon as the planned removal date is know. (It is up to the
maintainer if they want to remove the port immediately after the EOL date or
if
they want keep the port for some time with backported patches. Option two is
*not*
possible without backporting patches, see vulnerable ports) The general
suggestion
is that EOL versions should not stay in the ports tree for more than 3
months
without justification.
- The port does not adapt to infrastructure changes (i.e. USE_STAGE,
MANPREFIX,
compiler updates, etc.) within 6 months. Ports should be set to DEPRECATED
after 3
months and can be removed after 6
Reasons that do not warrant removal of a port:
- Software hasn’t seen a release in a long time
- Upstream looks inactive for a long time
Florian (on behalf of portmgr)
Thank you very much for your attempt to set precedence in this area. Your
proposal seems
well tempered and prudent. Thank you. Consider this a "+1" from me. :)
--Chris
--
--Chris Hutchinson
