Date: Sun, 11 May 2014 10:22:58 +0200 From: John Marino <freebsd.contact@marino.st> To: "Montgomery-Smith, Stephen" <stephen@missouri.edu>, Jonathan Chen <jonc@chen.org.nz>, "portmgr-feedback@freebsd.org" <portmgr-feedback@freebsd.org> Cc: FreeBSD Ports <ports@freebsd.org> Subject: Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st. Message-ID: <536F3362.3040509@marino.st> In-Reply-To: <536EDA23.6090401@missouri.edu> References: <536E46E0.7030906@FreeBSD.org> <CAJuc1zOvQAJB81BEThcpGh%2BGn6WbP74LAi3zQ=AWkTn-wCOyhg@mail.gmail.com> <536EDA23.6090401@missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <bdrewery@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?536F3362.3040509>