Date: Wed, 7 Sep 2011 21:37:07 +1000 From: Peter Jeremy <peterjeremy@acm.org> To: ports@freebsd.org Subject: Re: sysutils/cfs Message-ID: <20110907113707.GA30349@server.vk2pj.dyndns.org> In-Reply-To: <4e67a3b2.CVKcpQ8KQzuo8BP%2B%perryh@pluto.rain.com> References: <201109050933.p859XEbP004874@fire.js.berklix.net> <4E64C35A.50004@FreeBSD.org> <4e65b42e.M5K%2Bto11vAdk/UTk%perryh@pluto.rain.com> <4E6581E2.1060502@FreeBSD.org> <4e671817.ddHMkPbq9dJ7tLMz%perryh@pluto.rain.com> <4E66EFC5.3020201@FreeBSD.org> <4e67a3b2.CVKcpQ8KQzuo8BP%2B%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <stas@FreeBSD.org> 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 <code@apotheon.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110907113707.GA30349>