On 2/28/24 12: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.
If it is clear that guidelines could be interrupted/altered as
discussion opens up and that it isn't necessarily a set in stone process
as a result, it can put people's mind at ease that efforts are being
organized instead of people are just trying to stomp out things in a
quick and concise manner at the first justifiable chance.
I have and still use a python2 dependent program that is so niche
that I never saw it hit the ports tree (and didn't like my own porting
effort's results). I have not yet successfully migrated to a non python2
solution successfully; I lost all upstream support as others moved on to
new shiny things which I hope to do someday but they aren't direct
replacements. Obviously no one would keep python2 in ports for my case
then, but I did benefit from others having reasons that kept it there. I
also know that without, I could setup an old ports tree, and package
lock/jail/virtual machine my way through the problem.
Watching the python2 deprecation/removals kick into gear felt like a
weird clash between maintainer and user community. Looking back, I
wonder if a different solution of 'let someone else become maintainer'
may have been better since it was being triggered by an EOL instead of
vulnerabilities and broken builds.
Can EOL upstream case be clarified for when an upstream is required
and what meets said upstream? Some upstreams don't accept patches and
others seem to only fix things based on outside submitted patches. That
seems to blur the lines between upstream, community, and port maintainer
for who can do things. I figure my more extreme example above of python2
had a fight that EOL was important as vulnerabilities were common enough
and project was big enough that 1 or a few people would not be able to
guarantee a safe+working state; As safe is 'never' guaranteed anyways
which makes it more confusing there.
I forgot to mention it, but am still thankful for all who make the
ports tree happen: maintainers, users who submit PRs with/without
patches, general committers, and those who organize all of this
structure and flow. Though not perfect, all of that effort has lead to
making it a generally great experience over the years that I have used it.
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)
