Date: Wed, 12 Oct 2005 23:31:17 -0500 From: linimon@lonesome.com (Mark Linimon) To: Adam Weinberger <adamw@FreeBSD.org> Cc: Mark Linimon <linimon@lonesome.com>, cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/misc/iso-codes Makefile Message-ID: <20051013043117.GA24217@soaustin.net> In-Reply-To: <434DC405.8070904@FreeBSD.org> References: <200510130045.j9D0jdf2087285@repoman.freebsd.org> <20051013014733.GA19572@soaustin.net> <434DC405.8070904@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 12, 2005 at 10:18:45PM -0400, Adam Weinberger wrote: > Perhaps we could mark such ports as DEPRECATED, but instead introduce > a BIG_LOUD_WARNING variable that complains noisily but doesn't actually > prevent the port from being used? Same thing could be used for ports > with an incorrect pkg-plist. Before we started marking ports BROKEN for plist errors we had hundreds of ports with broken plists. Sending out general mail to the lists asking "won't people please fix this" had limited effect. After we started marking ports BROKEN for plist errors, we soon got down to a handful of ports with broken plists. This is just the way things work I suppose. But if there is community consensus that the way to go for ports that only fetch from the fallback site is to set DEPRECATED only (and not EXPIRATION_DATE), on the theory that the nag-mail from portsmon will be sufficient, then I personally will go along with it. In an "ideal" world these problems would be fixed as soon as they occur. However, I can tell you that after hacking and slashing my way through the newly revised distfile survey results, that it's just not happening that way. The amount of stale distfiles, many in ports maintained by FreeBSD committers, was and is very disheartening. Clearly Bill's and Edwin's surveys are the best thing to happen to the ports tree in many months, and I suppose it will take some time for people to catch up. Even better is Edwin's creating a tool so that individual maintainers can automate their own tests, and thus decentralize all this work. Anything that moves us along that direction is A Good Thing. But right now we've got a long way to go to eliminate even the really obviously broken things in the distfile survey. FWIW, there is no need for a BIG_LOUD_WARNING variable, the value of DEPRECATED is displayed to the user as soon as they start the install. mcl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051013043117.GA24217>