From owner-freebsd-ports@FreeBSD.ORG Wed Sep 7 11:37:12 2011 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33BCC106564A for ; Wed, 7 Sep 2011 11:37:12 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id B673E8FC0C for ; Wed, 7 Sep 2011 11:37:11 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p87Bb8Jv007401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Sep 2011 21:37:09 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p87Bb8W6099013 for ; Wed, 7 Sep 2011 21:37:08 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p87Bb8U1099012 for ports@freebsd.org; Wed, 7 Sep 2011 21:37:08 +1000 (EST) (envelope-from peter) Date: Wed, 7 Sep 2011 21:37:07 +1000 From: Peter Jeremy To: ports@freebsd.org Message-ID: <20110907113707.GA30349@server.vk2pj.dyndns.org> References: <201109050933.p859XEbP004874@fire.js.berklix.net> <4E64C35A.50004@FreeBSD.org> <4e65b42e.M5K+to11vAdk/UTk%perryh@pluto.rain.com> <4E6581E2.1060502@FreeBSD.org> <4e671817.ddHMkPbq9dJ7tLMz%perryh@pluto.rain.com> <4E66EFC5.3020201@FreeBSD.org> <4e67a3b2.CVKcpQ8KQzuo8BP+%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <4e67a3b2.CVKcpQ8KQzuo8BP+%perryh@pluto.rain.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: sysutils/cfs X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 11:37:12 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov wrote: >What about requiring that the ports deprecated should be either broken >or have known published vulnerabilties for a long period of >time (say 6 months) for the start? This might be reasonable for broken ports but ports with known vulnerabilities should either be fixed or removed promptly. > Personally, I'd also love to see >people deprecating ports provide a clear reasoning for deprecation in >the commit message (not just "deprecated some old ports" etc), so one >won't need to guess if he would like to fix/resurrect the port in the >feature? This is a reasonable requirement. On 2011-Sep-07 01:35:54 -0600, Chad Perrin wrote: >One thing I've seen come up that I definitely think would be a good idea, >though, is more accessible documentation of the CVS "attic", though. I >had no idea such a thing existed for old FreeBSD ports until fairly >recently, and still don't know much about it. Any VCS worthy of the name will retain history for objects that no longer exist because you might want to look at the state as it was at some point in the past when that object still existed. CVS stores the RCS masters for these deleted files is a subdirectory 'Attic' under the original directory. The data is only accessible via CVS - either using a local repository or via CVSweb. As an example, look at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/audio/xmms/?hideattic=3D0 > I would think that the >porter's handbook, at least, should mention it (perhaps with a brief >explanation of why and how one might make use of it). Again, it comes down to someone with the knowledge, motivation and time to write the content. On 2011-Sep-07 10:02:42 -0700, perryh@pluto.rain.com wrote: >Reread the first paragraph. Provided the port is still in the >tree, when they try to build it the ports mechanism reports the >FORBIDDEN/BROKEN/whatever which describes the problem, and the >expiration date a month or two out. =2E.. >In contrast, if the port is >_no longer_ in the tree, they have no clue why it disappeared. This last statement isn't true - when a port is moved or removed, a one-line reason for the change is added to /usr/ports/MOVED The package management tools are generally aware of this file. >It's only going to be removed if no one fixes it. The whole >point is that "release users" don't continuously monitor their >ports -- they only upgrade when they become aware that they >need to (e.g. when a newer release becomes available). This isn't necessarily a wise approach. > The >proposal is to increase the liklihood that, come upgrade time, >a "release user" gets a specific, actionable description of >any problems that have arisen, rather than having a port that >they have been using mysteriously disappear. Again, ports don't "mysteriously disappear" - there will be a record of why it was removed in the MOVED file. >Last I checked, freebsd.org was claiming that the very large number >of supported ports was a feature. It seems that some of the ports >committers disagree. Cleaning out the cruft will still leave a very large number of ports. And a better selling point is having a large number of functional ports - having a ports tree full of ports that are broken doesn't benefit anyone. >So define a variable along the lines of NEXT_PORT_PURGE_DATE >in one of the /usr/share/mk/bsd.port*.mk files, which (being >part of the base) _are_ branched, and when a situation of the >kind under discussion arises set the port's EXPIRATION_DATE >to NEXT_PORT_PURGE_DATE. Two issues: 1) Since the ports tree isn't branched and a port either exists or it doesn't exist, there needs to be a single expiration date. 2) There still needs to be a minimum expiration duration so you need a way to handle the case where a port is marked "to be purged" immediately before the NEXT_PORT_PURGE_DATE. --=20 Peter Jeremy --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk5nV2MACgkQ/opHv/APuId3PgCfTFMcf6pNlihLLlytFBqfCcMa 5lgAoKHtLaHW/tAd3mp2KLvHI/n/o4a5 =ooqg -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe--