ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.

[John Marino]

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 at 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