svn commit: r331880 - stable/11/etc

[Niclas Zeising]

On 04/10/18 04:28, Kyle Evans wrote:
> On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh <imp at bsdimp.com> wrote:
>>
>>
>> On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans <kevans at freebsd.org> wrote:
>>>
>>> Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
>>> and fix the ports to do the right thing for 12.x while that's still
>>> not a technically supported branch?
>>
>>
>> Don't back out the version bump. Other things may be riding along on it 'for
>> free'. Better to bump it again when you unMFC (if it's been more than a few
>> days since we've had one), and then yet-again when a fixed MFC happens.
>> Unless there's something you can ride along on for free :)
>>
>> Otherwise, that's a great plan.
> 
> Ok, I think the result of this thread and discussion with 0mp is the
> following set of actions:
> 
> 1.) One (1) commit to stable/11 to revert the MFC and bump
> FreeBSD_Version again for the removal
> 2.) One (1) commit to doc to document the new FreeBSD_Version
> 3.) Fixing ports to use the "new" behavior on 12, both the
> yet-to-be-patched ports and the ports that had already been patched
> under the assumption that it would still land first in 11.1-stable
> 4.) Documenting the original commit?
> 
> The hard part of point #3 has already been done by 0mp, who has
> submitted patches for all of the ports using this behavior. His
> patches will just need a bump of the version they're testing to the
> 12.x FreeBSD_Version and a fix-up on the patches that already landed.
> 
> For point #4, this seems like the type of breakage we should be
> documenting in release notes or something for the eventual upgrading
> of systems to 12.0. All usage of _limits stuff in custom rc scripts
> need to be audited, and all rc.conf(5)'s need to be scrubbed for
> ${name}_limits usage that doesn't make sense with the new context. I'm
> not sure what the most appropriate action here is, or what we should
> do this far ahead of time for such a thing.
> 
> If this sounds like a good path forward, I'll execute #1 and #2 in the
> morning (CST, so ~11 hours from this e-mail being sent).
> 

This still doesn't fix the issue of some early start up scripts 
depending on stuff that's not available yet, when for instance /usr is 
on a separate FS (which was the normal way to set up a system way back 
when).
This issue was first noticed more than 2 years ago, so someone did 
notice the breakage.  It just hasn't been fixed for an entire release cycle.
Regards
-- 
Niclas