Re: Proposed ports deprecation and removal policy

> On 28. Feb 2024, at 20:22, Florian Smeets <flo@freebsd.org> 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.
> 
> 

Hi Flo,

Thanks for the effort, it’s a delicate topic for many.

> 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:
> 

By whom though? Portmgr? Any committer?

> - 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.

How many ports in the tree would be affected by this policy at the moment?

Does “EOL versions“ also affect software where there are no new versions available (like, development officially stopped a long time ago or there was a license change, the project was archived etc.), or just outdated versions of software that is still under development? In any case, three months seems relatively short.

I’m maintaining a couple of ports where upstream officially stopped development, but which are still super useful (so they’re not just part of my personal software museum/there for sentimental reasons).

Best



> - 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)