From owner-freebsd-ports@FreeBSD.ORG Sun May 11 08:23:40 2014 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C5E8CFC; Sun, 11 May 2014 08:23:40 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27A512E52; Sun, 11 May 2014 08:23:39 +0000 (UTC) Received: from [192.168.0.20] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 3DCBC435C7; Sun, 11 May 2014 03:23:15 -0500 (CDT) Message-ID: <536F3362.3040509@marino.st> Date: Sun, 11 May 2014 10:22:58 +0200 From: John Marino Reply-To: marino@freebsd.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Montgomery-Smith, Stephen" , Jonathan Chen , "portmgr-feedback@freebsd.org" Subject: Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st. References: <536E46E0.7030906@FreeBSD.org> <536EDA23.6090401@missouri.edu> In-Reply-To: <536EDA23.6090401@missouri.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 08:23:40 -0000 On 5/11/2014 04:02, Montgomery-Smith, Stephen wrote: > On 05/10/2014 08:48 PM, Jonathan Chen wrote: >> On 11 May 2014 03:33, Bryan Drewery wrote: >> [...] >>> So we will be DEPRECATING and resetting maintainer on all unstaged ports >>> on June 31st. >>> >>> These ports will be set to EXPIRE on August 31st and will then be >>> removed from the tree. They will not be restored unless someone stages >>> them as well. >> >> The problem I have with this decision is that there are some complex >> ports which have no single maintainer (case in point: eclipse-devel); >> and whose patch-submitters only occasionally dabble with the port. >> Staging support for these ports sometimes tend to be over-complex, and >> one that yield no immediate benefit to the submitter. A port with no maintainer is always in danger of being pruned. By definition, it is not maintained. If collectively not a single user or freebsd ports committer thinks the effort of staging a port is worth the effort, then it means the port won't be missed. I don't think eclipse-devel will have that fate. >> >> And then there are the ports which have their have their home-baked >> installer, where adding staging support could mean wholesale changes >> to the port. Right. Thanks for noticing what's been happening for the last year. Even autotools (not home-backed) still needs to have DESTDIR added if support isn't there. It's often easier to skip the vender installer and create an install target in the port makefile. >> It used to be the philosophy of FreeBSD to favour pragmatism over >> ideology. I must admit to some disappointment over this decision to >> force staging as the "one true way". Stage is being required for a reason, it's a stepping stone. If you want to imagine that somebody brainwashed hundreds of people on philosophical terms and coaxed them to do all this extra work for no gain whatsoever, then please go right on doing so. > I have noticed that "make all" now includes the staging as well as > building. That is to say, it looks like there is a rather wholesale > reordering of how ports build and install. From this I conclude it is > becoming harder to include the legacy NO_STAGE code, which presumably > must stick to the old way of doing things. I don't understand this paragraph. I never use "make all" at the ports level. "make install" will do 2 steps: install into the staging area and then install onto the system. If you just want to install in the staging area, you use "make stage" target. By definition "all" is do everything, so that's not a surprise that's not a surprise. Maybe stop using "all"? A lone "make" is equivalent to "make build", so just use that perhaps? As far as legacy "NO_STAGE" goes... It's not just a matter of maintaining it - the requirement is that the port be staged. It's not a nice-to-have ideal, it's a requirement to stay in the ports tree. > Of course I might be wrong. But if I am right, then it will become > increasingly difficult to allow unstaged ports. Again, I don't understand. Unstaged ports will not be allowed. All unstaged ports will be removed from the tree, the reason giving that they aren't staged and nobody wants to do the work to stage them. This is not really about how hard it is to maintain NO_STAGE functionality, but rather the new functionality that can come after all ports are staged. JOhn