From owner-freebsd-ports@FreeBSD.ORG Wed Apr 27 20:04:01 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A6FA106564A for ; Wed, 27 Apr 2011 20:04:01 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp03.lnh.mail.rcn.net (smtp03.lnh.mail.rcn.net [207.172.157.103]) by mx1.freebsd.org (Postfix) with ESMTP id 1D11E8FC12 for ; Wed, 27 Apr 2011 20:04:00 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 27 Apr 2011 16:04:00 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.2.3-GA) with ESMTP id AVR08426; Wed, 27 Apr 2011 16:03:59 -0400 X-Auth-ID: anat Received: from 209-6-61-133.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com (HELO utka.zajac) ([209.6.61.133]) by smtp04.lnh.mail.rcn.net with ESMTP; 27 Apr 2011 16:03:58 -0400 Message-ID: <4DB876AE.9050906@aldan.algebra.com> Date: Wed, 27 Apr 2011 16:03:58 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101229 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eitan Adler References: <4DB6165F.1010806@FreeBSD.org> <20110426024122.GA38579@comcast.net> <20110426163424.GB38579@comcast.net> <20110426141209.0d07bccf@seibercom.net> <20110426184315.GA2320@libertas.local.camdensoftware.com> <19895.13977.553973.609431@jerusalem.litteratus.org> <4DB83D6E.9000800@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Robert Huff , Chip Camden , freebsd-ports@freebsd.org Subject: Re: saving a few ports from death 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, 27 Apr 2011 20:04:01 -0000 On 27.04.2011 14:16, Eitan Adler wrote: > Then bapt@ marked the ports*deprecated* which does not mean deleted. It was a warning that people who were interested should step up and take up the work. If after N amount of time no one does so they will be individually deleted. The ports I listed -- db2 and apache13* family -- are/were not broken. What "work" are you talking about? Yet, mandree deleted db2 on April 12th and dougb is anxious to delete apache13 as well instead of simply disowning it... >> > Maybe, for cleanliness and neatness, we should have a separate directory >> > (and category): "obsolete" -- where ports can go to die peacefully. But it >> > should not be cvs' "Attic"... > Who will be the ones to deal with that category, ensuring new > infrastructure works, etc? The port maintainer? oh wait! The same entity(ies), that currently busy themselves marking things "deprecated". But it was just a proposal -- for those, who don't like to see "obsolete" software mixed with the latest and greatest. I'm perfectly satisfied with not touching "obsolete" things at all. Certainly not until they break -- and stay broken for "too long". > cvs's Attic can be easily restored if people take up the slack. I see > no reason to change this policy No, not easily. It requires the CVS tree, which is not automatically installed. /usr/ports/obsoleted, on the other hand, would be rolled out together with the rest of the ports-tree. And, under my proposal, the packages for the "obsolete" stuff will continue building. The "if people take up the slack" seems to imply need to continuously work on the software. But the db2 needed no serious changes since 2004 and the last meaningful change was in 2008... The only reason to kill it was "too old"... Now all current users of db2 have to move onto later dbX, which means not only patching up the API-calls in their source-code (if the source code is even available!), but recreating their databases too -- because Berkeley DB files are not backwards-compatible. And for what reason?.. Same goes for apache13 -- last change was an upgrade to 1.3.42 (February 2010) -- it does not seem to require much work. There may well be good reasons to hate it, but somebody with a custom module, for example, may be perfectly satisfied with it... I happen to know one such site, for example. There may be more. If apache@ does not want it, they can drop maintainership. But deletion is not called for. Upgrading the OS should not /require/ upgrading (and replacing!) the applications. Yours, -mi