Date: Sat, 16 Mar 2024 01:48:30 +0000 From: void <void@f-m.fm> To: ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <2a868d2a-649e-4b76-870d-2cd8cfeb4f7d@app.fastmail.com> In-Reply-To: <2cfb2038d956813eefb068a8f61e1970@mail.infomaniak.com> References: <7a7501f71442d27f6d8c1c0a16f247c1@mail.infomaniak.com> <EF5FD6F9-D6EA-45F6-8845-B0476D401EBB@freebsd.org> <7fd610fa25ffb9a4348aaadf7459a689@mail.infomaniak.com> <20240315072753.46ffa39e1bbb2e0996099cdf@dec.sakura.ne.jp> <2cfb2038d956813eefb068a8f61e1970@mail.infomaniak.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a868d2a-649e-4b76-870d-2cd8cfeb4f7d>