On 2024-03-10 14:49, Daniel Engberg wrote:
On 2024-03-10T21:45:16.000+01:00, Eugene Grosbein <eu...@grosbein.net>
wrote:
29.02.2024 2:22, Florian Smeets wrote:
> 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
[skip]
> 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.
Objection to quoted reasons. A software not developed anymore but still
works fine
after years is best software ever. Do not touch it, please.
Some examples:
mail/qpopper abadoned by Qualcomm years ago
russian/d1489 created by ache@ who passed away years ago
net/quagga abadonware but still best OSPF implementation for FreeBSD
kernel
net-im/pidgin-manualsize abadoned by initial author years ago
databases/oracle8-client the only known library to link native FreeBSD code
with for OracleDB connection
Do not "fix" what ain't broken.
Eugene
I'm going to assume that there will be a PR or something regarding
maintained
ports either way.
In general not directed to the mentioned ports specifically but using a few
as examples,
As far as the "Do not "fix" what ain't broken" argument goes one major
concern is
how do you know especially regarding to Internet facing services? Qpopper
(for
example) has been dropped by pretty much every distro
https://repology.org/project/qpopper/versions and upstream is dead so
there's no
hub for communication. There likely aren't many eyes on the software by now
(I
guess for both good and bad reasons) but it might also very well bite you or
users
in the end. That being said, all software contains bugs including active
projects
so it's not like it's a clean cut in terms of security concerns (wordpress)
but
you'll likely see issues being adressed and reported when software is more
widely
available. If upstream is dead it's very likely that security reports ends
up in
some package repo, random hosted fork or such and never finds it way outside
of
it.
Quagga is in a similar position, pfsense seems to point users to frr and
there's
also other software such as bird/bird2 .
According to https://www.orafaq.com/wiki/Oracle_8 Oracle 8 support ended 20
years
ago, it's also marked as i386 only so its days are counted.
I'm going to suggest that this is a bit of a non-starter. Indeed as you say,
all software
may have (security) issues. wordpress, as you mention, is used by the FBSD
Foundation.
Windows requires a patch-of-the-day subscription. But there are *many* ports
that are
trivial utilitarian ports that are highly unlikely to be of any consistence,
and those
that do, would/should be under the purview of their respective maintainers. I
would submit
that it is the responsibility of the maintainer to ensure their continued
maintenance -- safety,
functionality, and availability. What is the responsibility of the
maintainer, if not to
maintain the port?
Nothing is stopping people to use an overlay but not everything needs to be
in or
rather stay the "public" repo forever.
Best regards,
Daniel
--
--Chris Hutchinson
