On 04/10/18 04:28, Kyle Evans wrote:
On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh <i...@bsdimp.com> wrote:
On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans <kev...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
