Date: Sun, 30 Aug 2020 12:11:55 -0600 From: Gary Aitken <freebsd@dreamchaser.org> To: Niclas Zeising <zeising@freebsd.org>, "Greg 'groggy' Lehey" <grog@FreeBSD.org> Cc: FreeBSD Developers <developers@freebsd.org>, ports@freebsd.org Subject: Re: Aggressive ports removal Message-ID: <3ef2fdf3-c746-2f57-ec2f-2f8784bfd5ce@dreamchaser.org> In-Reply-To: <f9cd7c4d-9477-89ab-f054-75b9bf9ca077@freebsd.org> References: <202008291154.07TBsr7L086597@repo.freebsd.org> <FC66C7DA-2A0D-43E7-B29C-E4C94C1973BA@freebsd.org> <f56625f8-1d63-515c-93af-909a4e47e65d@freebsd.org> <9a4583d9-097e-d0ba-4959-5c4d7b96b611@freebsd.org> <20200829232707.GC46173@eureka.lemis.com> <f9cd7c4d-9477-89ab-f054-75b9bf9ca077@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/30/20 2:28 AM, Niclas Zeising wrote: > On 2020-08-30 01:27, Greg 'groggy' Lehey wrote: >> Sorry for the length of the quotes, but I've added people who >> might not have seen the (relatively long) thread on this subject. >> This seems the best message to refer to. >> >> On Saturday, 29 August 2020 at 16:09:12 +0200, Stefan Esser wrote: >>> Am 29.08.20 um 15:32 schrieb Niclas Zeising: >>>> On 2020-08-29 14:48, Michael Gmelin wrote: >>>>> As I???ve seen quite a lot of similar commits: >>>>> >>>>> Is our policy now to deprecate ports (with one month notice) >>>>> that aren???t maintained/have a dead upstream, even though >>>>> the ports still work okay and aren???t the type that requires >>>>> much maintenance anyway? >>>>> >>>> >>>> Hi! As far as I know, there is no official policy, this was >>>> something that Tobias (tcberner@) and I (mostly I) agreed on, >>>> since we're doing a lot of the lifting when it comes to >>>> -fno-common. >>>> >>>> However, there is a lot of stale, old, unmaintained and >>>> possibly broken software in the Ports tree, and I viewed this >>>> as a chance to clean out some of the cruft. All these ports >>>> take resources from people needing to fix them, from the build >>>> cluster which is building them, and so on. Since there is no >>>> upstream fix for -fno-common, and there is no maintainer, I >>>> thought it would be a good idea to deprecate such ports, since >>>> there is no apparent interest in them. -fno-common is the new >>>> standard way of building C code (both llvm 11 and gcc 10 >>>> defaults to it). If someone is interested in the port, they >>>> can easily submit a PR to maintain the port and remove the >>>> deprecation (or commit the fix, if they are a FreeBSD >>>> committer). If they are removed, and someone in the future >>>> decides to take care of one (or more) of them, they can easily >>>> be resurrected, since they will live on in SVN (and git) >>>> history. >>> >>> No maintainer and no changes for a long time does not imply that >>> there is no interest in a port! >>> >>> If it just works, serves its purpose for those using a minimal >>> X11 environment (there are still twm users) and there is no >>> indication of a lingering security problem, then why depreciate >>> and later delete such a working port? >> >> Exactly. Another case in point: x11/xtset. Maintenance stopped >> in 1993, 11 days after the FreeBSD project came into existence. It >> works fine, and I find it very useful. If at some time in the >> future it should no longer work with the latest and greatest >> iteration of the C programming language or ports structure, that >> shouldn't be a reason to discard it. > > Then it is very easy. If it is useful to you, adopt it as > maintainer, then you will get a notification if it fails to build, > and you can fix the issue(s), instead of trusting that someone has > the time and energy to fix it. At the same time you indicate that > there is actually some interest in the port. We set deprecation dates > in the future so that interested parties should have a chance to > speak up. > >> >> My suggestion: >> >> 1. Decisions to deprecate remove ports should be made only by >> portmgr@. > > This is like saying you don't trust ports developers. Any work on > the ports tree would grind to a complete halt. > >> 2. Ports are not broken because they don't easily adapt to some >> new ports framework. > > This is simply not true. Ports that don't adopt to a new ports > framework are broken. New ports frameworks are developed to ease in > porting, packaging or to improve or simplify ports, the same way as > new kernel or base frameworks are invented. Things that do not > comply with the new way of things are hindering progress and updates, > and need to be either adapted or removed. It is exactly the same as > for instance the removal of the Giant lock. The difference might be > the rate of change. Since FreeBSD base has fixed releases and stable > branches, but the ports tree mostly a rolling release model (that has > to work on 3-4 different FreeBSD versions at the same time) the rate > of change in the ports tree are necessarily higher. > >> 3. Ports should not be removed without community consultation, >> which should last for at least n months, with m reminders being >> sent. > > I agree with the reminders. Every time you install a deprecated port > or package you'll get just such a notification. Regards I don't know how easy this would be to implement, but it would be very useful to know which ports are actually being built and installed. How difficult would it be to have pkg install and the make install script do some counting and a cron job forward the counts to freebsd.org? That would give a much better sense of how useful a port is. Yes, it's inaccurate given rebuilds, upgrades, etc., but if a port shows zero installs for several years it seems like it could be sidelined. Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ef2fdf3-c746-2f57-ec2f-2f8784bfd5ce>