On 16/03/2024 02:48, void wrote:
On Thu, 14 Mar 2024, at 22:59, Daniel Engberg wrote:
Since we've moved to git perhaps another option might be to create a separate
repo (possibly via submodules) with less restricive polices and have
that as an "add-on" for the official tree without the ports team's and
committers's involvement, a bit like "you're on your own" approach?
100% agree with this. Stuff with an active maintainer: keep in the official
tree.
Stuff without, or stuff that depends on stuff without - into the
'unsupported' tree. Some distros (notably Debian) do this. It's 2024
not 1994 and most computers are connected to the internet either directly or
indirectly. I'd argue there is no place in the official tree for
poorly/non-maintained ports.
I imagine having such a system would markedly decrease the maintenance burden
of those responsible for the port infrastructure.
As a user of ports (a dev only in the sense of reporting issues if one can be a
dev in that sense) i feel it would be better to *not have a port at all in the
official tree* than to have one which is not maintained and possibly or probably
vulnerable. Remember that not all vulns make it into the vulxml. Having
different trees would help new and older users alike to trust ports, and would
add
to transparency of freebsd generally.
just my $0.02
Maintained ports are vulnerable as well, and sometimes somebody else has
to submit a patch for an updated version to fix the vulnerability. (I
personally have this experience)
For vulnerabilities, there is VuXML and pkg audit, not removing
vulnerable port from the tree.
If you are asking to remove ports without maintainer, you are asking to
remove 3458 ports right now, and many others depends on these
unmaintained ports, so the impact will be much bigger.
Some unmaintained ports are almost vital - for example without
virtual_oss you cannot use Bluetooth headphones / speakers connected to
FreeBSD.
Therefore writing "one size fits all" rules for 32k+ ports is not that
easy. There are too many personal views to this simple problem.
Kind regards
Miroslav Lachman
