From owner-freebsd-ports@FreeBSD.ORG Sat Sep 10 10:24:36 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 CDCE5106566B for ; Sat, 10 Sep 2011 10:24:36 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 3B1488FC08 for ; Sat, 10 Sep 2011 10:24:35 +0000 (UTC) Received: (qmail invoked by alias); 10 Sep 2011 10:24:34 -0000 Received: from g227136144.adsl.alicedsl.de (EHLO apollo.emma.line.org) [92.227.136.144] by mail.gmx.net (mp040) with SMTP; 10 Sep 2011 12:24:34 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX19sHFlGqcFsmM/4y+zDn2KjK7h314VJs+NdsBZeBC JgUD2z88C0zY86 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id A28D123CE28; Sat, 10 Sep 2011 12:24:33 +0200 (CEST) Message-ID: <4E6B3AE1.80100@gmx.de> Date: Sat, 10 Sep 2011 12:24:33 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Mnenhy/0.8.3 Thunderbird/3.1.13 MIME-Version: 1.0 To: freebsd-ports@freebsd.org References: <4E651DCF.30605@FreeBSD.org> <201109052146.p85Lkous037023@fire.js.berklix.net> <4E67935C.6080702@aldan.algebra.com> <4E68AC85.4060705@icritical.com> <4E68F34C.6090504@FreeBSD.org> <20110909040954.17733a4e@cox.net> <4E6A476D.7090800@gmx.de> <20110910004553.610dc809@cox.net> In-Reply-To: <20110910004553.610dc809@cox.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: conrads@cox.net Subject: Re: ports deprecations (was: 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: Sat, 10 Sep 2011 10:24:37 -0000 Am 10.09.2011 07:45, schrieb Conrad J. Sabatier: >>> Frankly, I'm growing increasingly concerned that this push to >>> eliminate ports is getting out of control. I don't much care for >>> the notion that, having invested the time in installing, >>> configuring and tuning a certain set of software packages, suddenly >>> the rug could be pulled out from under me, so to speak, in essence >>> *forcing* me to abandon using certain packages or else deal with >>> maintaining them (in the ports maintainer sense) on my own. >> >> The rug is pulled by the upstream maintainers abandoning their >> software, not by FreeBSD no longer packaging it years after the fact. > > While I understand the reasoning behind this, I still feel that as long > as a package continues to build and run without any known issues, then > why be in a rush to drop it? The argument that "the ports collection > is not a museum" is valid to some degree, but if a package is still > usable (and useful), then aren't we shooting ourselves in the foot by > dropping it? Conrad, (courtesy Cc: after changed subject, please reply to the list) I'd see that as proactive maintenance. If there is no upstream maintainer any more, chances is that one time the port needs code changes to adapt to changes in underlying libraries. For the sake of argument, let's assume this example (I'm not sure if libpng would be a real-world instance of it, I didn't care enough to have a closer look): There are points in time when dead port X using a changed library Y needs code changes, for instance, if library Y in some old unmaintained version is vulnerable, and its fixed versions have a different API. Now, if we tell people soon enough that they may run into that problem, chances are that people never hit the problem, and chances are that people hit the problem soon - and the fewer users of the dead port are forced to make the switch, the better. The open question is, is there a point in marking a point DEPRECATED without giving an expiration date. My personal answer is "no" because no-one will believe in a DEPRECATED tag without EXPIRATION_DATE and people will be disappointed because they've grown used to custom and practice and I can already see the "we told you it was DEPRECATED". The real point is that the FreeBSD ports system can not fill in for the maintainers of discontinued ports. There is a certain pragmatism to "as long as it builds, appears to work, and there are no known critical bugs, let's keep it", but it has this organizational drawback that it becomes custom and practice at some time, and ends up hurting more people in the end. Best regards, Matthias