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.
We tried to find a sensible middle ground between too fast removal and
keeping unmaintained and abandoned upstream software in our ports tree
forever.
Not otherwise mentioned in this post, there is value in considering
the difference between unmaintained upstream, unmaintained from an
inactive port maintainer, unmaintained from an interested port
maintainer that is unable to solve the problems they have been presented
with or find helpers who did, and unmaintained due to no maintainer for
the port.
Is there a recommendation, and way to go about it, for port
maintainers to preemptively mention extended away time like
vacation/holiday or longer?
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.
I presume 'progress' means things like 'blocks ports framework
updates' as cases were mentioned of later, but was this the intent?
Removing a port that causes conflict building/installing another could
be considered progress.
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
As some ports don't really have a WWW this may be a bit harsh in
special cases where community interaction beyond source code is through
a mailing list, chatroom, discord, etc. Some websites may be neglected
or left to expire due to little interest from who ran it even though a
project isn't similarly dead.
- BROKEN for more than 6 months
Presume this is a 'broken for everyone on supported FreeBSD releases'
though should probably also include stable and current before deletion
can happen.
I have seen results, besides just a 'BROKEN' being set, from ports
with maintainers that had a PR with a maintainer's patch that fixed a
problem go for months without being committed. I hope a rush to
mark/remove ports as this email implies would lead to more efficient
flow rather than creating more work by actions that would be a mistake
in such cases.
- has known vulnerabilities that weren’t addressed in the ports tree for
more than 3 months
Will the scope of a vulnerability be considered? As an example,
removing virtualbox because of a network vulnerability means users who
do not need such capability lost the port too.
Trying to follow CVEs has made it clear to me that some end up being
bugs or possibly unexpected program operation that doesn't seem to have
any known example of how the bug is even a security issue.
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.
Are we thinking of 'old version' cases such as python27, or even
cases where upstream EOL'd the project as a whole? Would it be handled
differently if an alternative exists or not and if an alternative
community can be switched to for further project coordination?
- 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
Some ports are not hier compatible in general even though they are
still useful ports. How are exceptions to be decided? Are they marked as
an exception in the Makefile?
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)
No maintainer + no upstream maintenance when issues have arisen
(security, build, infrastructure compatibility) seems like a good time
for marking for removal as a general concept though it seems many ports
I use, or just try out, regularly don't have maintainers. As issues
arise, people often step up and report them or fix them as nonmaintainer
which then get committed. I feel I'm not the best choice for maintainer
as I am not active enough and often find I go periods where I don't pay
active attention; my email often goes through phases where it doesn't
get looked at if I'm not actively looking for something. I also found
through experience that simple porting problems often go beyond my
abilities.
Some ports would likely benefit from just having a maintainer as
someone who coordinates the effort to keep it working even creating the
port+patches is beyond them. This could be a point of failure if they
recommend submitted patches be committed without requesting outside help
reviewing them such as for safety. Could we document more clearly if
such a maintainer is desired and if it is, even recommend it in the
all-too-common 'this port has no maintainer' messages?
Similarly, pkg could really benefit from listing that message once
with a list of ports it applies to as I find the messages basically just
become noise at this point.
