From owner-freebsd-ports@FreeBSD.ORG Thu Sep 8 06:20:29 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 170551065670; Thu, 8 Sep 2011 06:20:29 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7EE68FC0C; Thu, 8 Sep 2011 06:20:28 +0000 (UTC) Received: by gyf2 with SMTP id 2so437151gyf.13 for ; Wed, 07 Sep 2011 23:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YA8AbgoM/jHLIbMSMCixEmsAj8xFfdWoYYP5ZuOi92c=; b=DmRdQtm0FBEShcOIwYHEeJu30JsqRmjU8WAmp3pS4FF8azOPu13WqACKeIUjHmxZ0P qUhdxeuW4aDJJCa2fAshqYBYFGwqyoDkTTH9zDx+CeekD+0yEEsMWIxcf02Fd6HssMpF oF8KJeq1pWDUWC2UbIHuCTuA9pW/QjUx18XtY= MIME-Version: 1.0 Received: by 10.231.26.68 with SMTP id d4mr234942ibc.66.1315462827929; Wed, 07 Sep 2011 23:20:27 -0700 (PDT) Received: by 10.231.61.148 with HTTP; Wed, 7 Sep 2011 23:20:27 -0700 (PDT) Received: by 10.231.61.148 with HTTP; Wed, 7 Sep 2011 23:20:27 -0700 (PDT) In-Reply-To: <201109080128.p881SVZF021424@fire.js.berklix.net> References: <4E67F41F.70401@FreeBSD.org> <201109080128.p881SVZF021424@fire.js.berklix.net> Date: Thu, 8 Sep 2011 07:20:27 +0100 Message-ID: From: Chris Rees To: "Julian H. Stacey" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, Doug Barton , perryh@pluto.rain.com 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: Thu, 08 Sep 2011 06:20:29 -0000 On 8 Sep 2011 02:29, "Julian H. Stacey" wrote: > > Hi, > Reference: > > From: Doug Barton > > Date: Wed, 07 Sep 2011 15:45:51 -0700 > > Message-id: <4E67F41F.70401@FreeBSD.org> > > Doug Barton wrote: > > On 9/7/2011 10:02 AM, perryh@pluto.rain.com wrote: > > > Doug Barton wrote: > > >> On 09/07/2011 00:07, perryh@pluto.rain.com wrote: > > >>> Doug Barton wrote: > > >>>>>>>>> Better to deprecate such non urgent ports, & wait a while > > >>>>>>>>> after next release is rolled, to give release users a warning > > >>>>>>>>> & some time to volunteer ... > > >>>>>> > > >>>>>> That's an interesting idea, but incredibly unlikely to happen. > > >>>>> > > >>>>> It _certainly_ won't happen if those in charge refuse to try it! > > >>>> > > >>>> My point was that the idea is impractical ... > > >>> > > >>> How is it impractical to, as a rule, set an expiration date based > > >>> on an anticipated future release date rather than only a month or > > >>> two out from when the decision is made? > > >> > > >> As has repeatedly been explained to you ... > > > > > > I think you may have gotten me confused with someone else. > > > > Quite possibly. :) Saying the same things over and over again gets > > mentally exhausting after a while. > > > > >> you're asking the wrong question. The question is, how does it > > >> benefit the users to leave it in when we know that we're going > > >> to delete it? Either way the user will discover that the port > > >> is not easily available for installation when they update their > > >> ports tree. > > > > > > 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. (If the expiration date is > > > not included in the report, it should be.) They then know that > > > they need to fix the port, or find someone to fix it, and they > > > know _why_ it needs to be fixed. In contrast, if the port is > > > _no longer_ in the tree, they have no clue why it disappeared. > > > > As was pointed out elsewhere in the thread, the MOVED entry should > > contain that information. Generally what I do when I actually remove a > > port is to copy the DEPRECATED/FORBIDDEN message into the MOVED file entry. > > > > However, even if that isn't sufficient the entire story is still > > available in the CVS history. And the user can always ask on > > freebsd-ports@ if they are really confused and need help. > > > > >> The difference is that in the meantime people doing work on > > >> the ports tree don't have to work around the old port (that's > > >> going to be removed anyway). > > > > > > It's only going to be removed if no one fixes it. > > > > .. which is what happens in the vast majority of cases. > > > > > 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). > > > > And what we have been trying to explain to you is that this has never > > been a supported mode of operation. We don't tie the ports tree to > > specific releases, > > [ I've been reading & not writing , as real life priorities intrude, > but that phrase has been repeated too often to ignore ...] > > FreeBSD doese "tie the ports tree to specific releases". We have ports > freezes before each release We don't, actually.