Date: Sat, 16 Mar 2024 17:56:27 +0000 From: void <void@f-m.fm> To: ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <a21cba77-42ba-4a66-ab45-862efa34fdf9@app.fastmail.com> In-Reply-To: <883C5440-68BE-4ECC-9CB6-E30253E931C9@freebsd.org> References: <496936f9-b925-4dd4-9e86-6220088fb964@app.fastmail.com> <883C5440-68BE-4ECC-9CB6-E30253E931C9@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Mar 2024, at 10:28, Michael Gmelin wrote: > Seriously, the =E2=80=9Cother=E2=80=9D tree would rot in no time, this= is not practical=20 > (it=E2=80=99s also interesting how the discussion moved from =E2=80=98= ports=20 > unmaintained upstream=E2=80=99 to =E2=80=98ports without a maintainer=E2= =80=99).=20 Look at it another way: how come something like it *is* practical=20 for other OSes (including distros)? > If the goal is to have a pure system nobody uses, please go ahead. The "goal" would be to have a reasonably up-to-date, and as vuln-free as can be reasonably attained, freebsd system that uses the "maintained" port tree. > I (still) think an approach where `pkg audit`warns about unmaintained=20 > ports (and ports without an upstream maintainer), maybe even having=20 > config options that prevent the installation of such ports - which=20 > could be on by default - would be a way to allow people to make=20 > informed decisions without removing these ports from the tree. That's a good idea. --=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a21cba77-42ba-4a66-ab45-862efa34fdf9>