From owner-freebsd-ports@FreeBSD.ORG Sat Nov 22 23:50:43 2014 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE81031B for ; Sat, 22 Nov 2014 23:50:43 +0000 (UTC) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FCC2378 for ; Sat, 22 Nov 2014 23:50:43 +0000 (UTC) X_CMAE_Category: , , X-CNFS-Analysis: v=2.0 cv=cMhiQyiN c=1 sm=1 a=dUPDVWa3Dxp/u6Q+mY+wRA==:17 a=5bAhRdOea6EA:10 a=LaogzpLLAAAA:8 a=yPCof4ZbAAAA:8 a=Bz5OPBB9u6Q7XlqmL8wA:9 a=QEXdDO2ut3YA:10 a=bfqHO45p1xYA:10 a=pGLkceISAAAA:8 a=Pb7YBSJeCTY275g_cUgA:9 a=_W_S_7VecoQA:10 a=dUPDVWa3Dxp/u6Q+mY+wRA==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YW5hdEByY24uY29t Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=mi+thun@aldan.algebra.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=mi+thun@aldan.algebra.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=anat; auth=pass (PLAIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 100.1.235.44 is neither permitted nor denied by domain of aldan.algebra.com) Received: from [100.1.235.44] ([100.1.235.44:50237] helo=[192.168.1.8]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES128-SHA) id 77/1E-33849-15121745; Sat, 22 Nov 2014 18:50:41 -0500 Message-ID: <54712150.70209@aldan.algebra.com> Date: Sat, 22 Nov 2014 18:50:40 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: Overly aggressive obsoleting of ports (Re: FreeBSD ports which are currently scheduled for deletion) References: <201411210828.sAL8SQuR036287@portsmon.freebsd.org> <546F54B1.9000508@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "ports@FreeBSD.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 23:50:44 -0000 On 22.11.2014 18:19, Kevin Oberman wrote: > It's not like FreeBSD has a to of choice when the BerkeleyDB folks > have dropped db-4.8. I don't see a connection... People getting their software from Oracle may have a point to make with the vendor. I'm talking about those, who install it via FreeBSD port. Nor do I see, what you mean by "have dropped" -- certainly, the manual is still there: https://docs.oracle.com/cd/E17275_01/html/programmer_reference/changelog_4_8.html As is the tarball. More generally, I do not believe, our decision to drop a particular package should be based on that of the software's authors/vendors -- unless their license requires us to, of course. Sure, it usually makes little sense to keep a port of foo-X, when foo-(X+1) is available. But some software groups -- like BerkeleyDB or KDE -- have historically been obnoxiously bad about compatibility with their own older releases. In these situations, FreeBSD ought to keep it easy for our users to stay with the old version for much longer, than we have been doing lately... > It's been obsolete for a very long time. db-4.8.30 was released in 2010. That is not "a very long time" ago. Not at all. Even if it were declared "obsolete" back then -- which it was not... > You just need to re-install them. What of the organizations' own projects, which rely on BerkeleyDB? Even if they do all continue to work after changing, verifying it takes time. Worse, major upgrades of BerkeleyDB require migrating the data. It is not a trivial task some times -- especially with large databases (such as an LDAP user-database of a major company). Heck, even an Apache-upgrade from 2.4.x to 2.4.y can be a minefield some times, even when nothing was /supposed/ to have changed. With BerkeleyDB, coming up with upgrade instructions and the scripts for dump-ing and restore-ing of existing databases -- required planning and man-days of development, testing, and roll-out efforts. Suggesting, such efforts must be undertaken immediately -- on a whim of our portmgr@ team -- is simply a non-starter. Do you want to tell companies using FreeBSD, that ports/ can not be relied on for anything mission-critical? Well, I guess, you might be right if you said that today, but the goal ought to be to reverse that unfortunate trend, not to accelerate it... -mi