Bug 242619

Summary: Mk/bsd.port.mk: Messaging around ALLOW_UNSUPPORTED_SYSTEM is confusing
Product: Ports & Packages Reporter: mircx1 <mircx123>
Component: Individual Port(s)Assignee: Kubilay Kocak <koobs>
Status: Open ---    
Severity: Affects Some People CC: dewayne, portmaster, ports-bugs
Priority: --- Keywords: needs-patch, needs-qa
Version: Latest   
Hardware: amd64   
OS: Any   

Description mircx1 2019-12-13 08:12:38 UTC
hello this a long time i try install from a ports and i get error
root@asher:/usr/ports/accessibility/accerciser # cd /usr/ports/accessibility/accerciser/ && make install clean
/!\ ERROR: /!\

Ports Collection support for your FreeBSD version has ended, and no ports are
guaranteed to build on this system. Please upgrade to a supported release.

No support will be provided if you silence this message by defining
ALLOW_UNSUPPORTED_SYSTEM.

*** Error code 1
i make update everything not work
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-12-13 09:24:23 UTC
This is an intended message, indicating that the system is running an end-of-life version of FreeBSD. Please update to a supported release version using one of the methods documented here: https://www.freebsd.org/doc/handbook/updating-upgrading.html
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2019-12-13 09:26:44 UTC
Note: While the system is reporting 11.3-p5 (kernel), the system in question is running an older userland, likely due to an incomplete/partial upgrade process (via IRC)
Comment 3 mircx1 2019-12-13 09:36:53 UTC
i make everything and nothing even i inside to etc make conf and i set it

ALLOW_UNSUPPORTED_SYSTEM=YES
Comment 4 mircx1 2019-12-13 10:20:44 UTC
i make upgrade amd nothing the version 11.3-p5 stop install from ports then if someone to know something how i can fix it i to be happy
Comment 5 Chris Hutchinson 2019-12-14 06:05:01 UTC
(In reply to mircx1 from comment #3)
I can also report this does *not* work
as expected (intended?).
I performed an experiment using a so-called
"unsupported" version. I needed to test some
ports I maintain. In any event; adding:
ALLOW_UNSUPPORTED_SYSTEM=true
effectively accomplishes nothing.
There is also the problem with each invocation
of this informational warning having a 10 second
timer attached to it.
As such setting up an environment that builds/installs
~1500-2000 ports requires waiting 15,000-20,000 additional
seconds -- that's as much as 333.33333 minutes, or 5 hours;
( 2000x10/60/60 ).
If I'm not mistaken, the knob ALLOW_UNSUPPORTED_SYSTEM
is/was intended to silence this warning.
Really. If you've seen this warning, and acknowledged it
by adding the knob to make.conf(5). You should be done.
Simply removing the "silence this message by defining
ALLOW_UNSUPPORTED_SYSTEM." from the warning, and repeating
the warning, and 10 second pause. Has no value what-so-ever.
I spent some time attempting to fix this. But got distracted
by having to fix Mk/Uses/python.mk.

I don't know that I can find the time to fix this right now.
But someone well familiar with the ports(7) framework should
be able to accomplish it in ~10-15 minutes.

This matter should *not* have been closed. If need be, I will
re-open this case by starting a fresh new pr(1) for this matter.

--Chris
Comment 6 dewayne 2019-12-14 06:20:39 UTC
(In reply to Chris Hutchinson from comment #5)
Yes, those delays are annoying, especially when ports are built in batch.  I'd suggest setting
WARNING_WAIT=0
DEV_WARNING_WAIT=0
in make.conf, which eventually become "sleep 0".  Doesn't come anywhere near fixing your problem only reducing the nuisance.
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2019-12-14 06:50:13 UTC
(In reply to Chris Hutchinson from comment #5)

There's no need to create a new/separate bug for addressing the specific issue mentioned in the summary, namely: eol error being present.

However, if this specific  issue can indeed be verified, information provided such that it can be reproduced, and a 'problem' clearly described (expected vs actual behaviour), rlease re-open this issue with a proposed patch and a modification of the issue summary, if appropriate.

Open questions on this issue are:

- Is the problem that the error comes up at all on an 11.3-p5 system at this time?
- Is the problem that the error comes up in certain situations of a 
partial/incomplete upgrade process and it shouldn't come up at all?
- What are the steps to reproduce?
- What is the exact state of the system experiencing the issue?

At present this bug does not contain information sufficient to take action, hence the present resolution "works as intended".

Comments on, and the issue of the timeout, or improving it in BATCH situations should take place and addressed in a separate issue.
Comment 8 Chris Hutchinson 2019-12-14 07:18:51 UTC
(In reply to Kubilay Kocak from comment #7)
I only mentioned opening a new pr(1) as this one was
closed, and because I didn't initiate it, I couldn't
re-open it. Thank you for tending to it. :)

Attempt to answer (remaining) open question(s):
 * It fires properly *when* it encounters EOL'd systems
 * It correctly informs, and directs the user for the circumstances
However
 * It does NOT respond as indicated when doing as instructed --
   adding: ALLOW_UNSUPPORTED_SYSTEM=true/yes/t/...
   will NOT silence the warning
 * which *also* (continues to) impose a 10 second pause

The *understood* purpose of the warning (and pause). Was to
inform the user that the version that their system is on, is now
EOL. They should upgrade as soon as is possible.
BUT, if for some reason they need to continue on the EOL'd
system. For convenience; you may silence this message by adding
ALLOW_UNSUPPORTED_SYSTEM=true you your make.conf(5).

This is what the message clearly states. But adding it to make.conf(5)
only removes the portion of the message that states what to
add to make.conf(5). It does NOT remove the rest of the message,
or the 10 second pause.

This is clearly not what was intended. No? :)

Thanks again, for taking the time to address this matter.

--Chris
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2019-12-15 01:57:37 UTC
(In reply to Chris Hutchinson from comment #8)

I can't *unequivocally* speak to the original intention, but looking at the relevant block in Mk/bsd.port.mk:

- There are two 'variations' of the message depending on whether ALLOW_UNSUPPORTED_SYSTEM is defined or not, and 

- *both* conditions include the same message as their first section, 

- with the latter (when not defined) additionally including the "... if you silence this message by defining ALLOW_UNSUPPORTED_SYSTEM"

To me, that indicates that defining ALLOW_UNSUPPORTED_SYSTEM was *not* supposed to  or intended get rid of the EoL messaging *completely*.

I conclude that the mechanism indeed 'works as intended' on the above basis, but I believe there is some messaging improvements to be made, as I can see how "silence this message" could be taken to mean "not see any message about this EoL condition *at all*", rather than "just remove the messaging about being able to use the ALLOW_UNSUPPORTED_SYSTEM variable"

I would propose a simple change such as:

- No support will be provided if you *silence this message* by defining ALLOW_UNSUPPORTED_SYSTEM.
+ No support will be provided if you *override this error* by defining ALLOW_UNSUPPORTED_SYSTEM in /etc/make.conf
Comment 10 mircx1 2019-12-15 07:44:13 UTC
when i will make update to 11.3-p5 the ports stop to install if you know how i can fix it i to be happy
Comment 11 Chris Hutchinson 2019-12-15 22:07:52 UTC
(In reply to Kubilay Kocak from comment #9)
Message returned for an EOL system:
/!\\ ERROR: /!\\
Ports Collection support for your ${OPSYS} version has ended, and no ports
are guaranteed to build on this system. Please upgrade to a supported release.
No support will be provided if you silence this message by defining ALLOW_UNSUPPORTED_SYSTEM.

PERCIEVED message:
System is no longer supported
Add ALLOW_UNSUPPORTED_SYSTEM=true/yes/t/... to make.conf(5) to silence (remove)
this message

Rational:
Having been submitted this message. I now know my system is EOL.
Now that I *know* it is EOL. I can remove this (now redundant) message,
by setting ALLOW_UNSUPPORTED_SYSTEM=true/yes/t/... in my make.conf(5)

Why:
There is
1) no *other* value in creating ALLOW_UNSUPPORTED_SYSTEM
2) I *already* know the system is EOL, and have proved that by adding
ALLOW_UNSUPPORTED_SYSTEM to make.conf(5)

Need:
I am a ports maintainer for well over 100 ports. When I need to test
against older systems. I should *not* be penalized by
1) the redundant message
2) as much as a 5 hour delay building the ports I am testing, and
related ports required to create the test.

The original message is created by 2 variables
Setting ALLOW_UNSUPPORTED_SYSTEM only removes the portion of the message
that says you can add it. It has *no* other value. It has no *realistic*
value.

Proposal:
Make the message controlled by *only* the *second* variable. Which will
remove the message, and 10 second pause, should the user acknowledge they
know their system is EOL, by seetting ALLOW_UNSUPPORTED_SYSTEM in make.conf(5)

Thank you for your continued attention to this issue.

--Chris
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2019-12-15 23:54:34 UTC
(In reply to Chris Hutchinson from comment #11)

I'm hearing a proposal that ALLOW_UNSUPPORTED_SYSTEM should not just remove the messaging about the variable being available, but to bypass the EoL message completely, given that a user has already been informed (given theyre using the variable) that the system is EoL.

That's fine, if you could provide a proposed patch to do so, that would be great

Regarding the time delay, per comment 7:

>  Comments on, and the issue of the timeout, or improving it in BATCH situations > should take place and addressed in a separate issue.

If you could create a separate issue with a patch for that, that would also be appreciated