Date: Mon, 26 Oct 2020 13:26:50 +0100 From: Stefan Esser <se@freebsd.org> To: rgrimes@freebsd.org, Alex Kozlov <ak@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r366962 - in head: include usr.bin/calendar Message-ID: <25230c39-fc65-ec95-58e6-381f8f18a226@freebsd.org> In-Reply-To: <202010252355.09PNthB5080260@gndrsh.dnsmgr.net> References: <202010252355.09PNthB5080260@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 26.10.20 um 00:55 schrieb Rodney W. Grimes: > [ Charset ISO-8859-1 unsupported, converting... ] >> On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote: >>> Am 24.10.20 um 09:48 schrieb Alex Kozlov: >>>> On Fri, Oct 23, 2020 at 09:22:23AM +0000, Stefan E?er wrote: >>>>> Author: se >>>>> Date: Fri Oct 23 09:22:23 2020 >>>>> New Revision: 366962 >>>>> URL: https://svnweb.freebsd.org/changeset/base/366962 >>>>> >>>>> Log: >>>>> Add search of LOCALBASE/share/calendar for calendars supplied by a port. >>>>> Calendar files in LOCALBASE override similarily named ones in the base >>>>> system. This could easily be changed if the base system calendars should >>>>> have precedence, but it could lead to a violation of POLA since then the >>>>> port's files were ignored unless those in base have been deleted. >>>>> There was no definition of _PATH_LOCALBASE in paths.h, but verbatim uses >>>>> of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to ease >>>>> a consistent modification of this prefix. >>>> You are hardcoding assumption that LOCALBASE = /usr/local. Please make it >>>> overridable with LOCALBASE environment variable. >>> This was a trivial change to get us going with calendars provided by >>> a port (which has not been committed, yet - therefore there are no >>> port-provided calendars, neither under /usr/local nor under any other >>> PREFIX, as of now). >> >>> I understand what you are asking for, but in such a case I'd rather >>> think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in >>> paths.h. >> The PREFIX != LOCALBASE and both != /usr/local configurations >> are supported in the ports tree and the base for a long time, please see >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html > > Seems all that work for all them years is about to be tossed out > the window as "an out dated concept". The world outside this project has grown at a much faster rate than what the project provides. The FreeBSD base system is very usable as a development system with its integration of editor, compiler, debugger and the like, but the huge magnitude of software actually used for development today is not included. We need to treat ports/packages as necessary extensions of the system, and thus we need to have hooks in the base system, that allow to easily integrate such add-on packages. And more and more extensions that have to be integrated into base system functionality have been developed outside our project. We can ignore them or use them, but in the latter case need hooks in the base system (including references to paths below LOCALBASE). >> If after this commit you need to rebuild base to use non-default LOCALBASE/PREFIX >> it is pretty big regression and POLA. > > I guess no one is paying attention to any of this... What has that got to do with the change I propose? Recompiling for a different LOCALBASE requires identifying and patching tens of files distributed over our source tree. I'm trying to identify those locations and use a parameter that can be changed at a well known location (the paths.h file) to at least make a changed LOCALBASE practical with a re-compilation. >>> And I have made this a single instance that needs to be changed. >>> Before my change there were 2 instances of /usr/local hard-coded >>> in _PATH_DEFPATH - now you have to only change the definition of >>> _PATH_LOCALBASE to adjust all 3 locations that use it. >> I think you made situation worse, there were two stray hardcoded >> string and now there is official LOCALBASE define which likely will be >> used by other people in the future. > > Yep, and now that propogation is about to occur. Sorry, but whether there are more references to LOCALBASE in our base system will depend on whether it is useful for some purpose. Having a path defined in paths.h does not lead to it being used in more places. And if it was, there was no qualitative change, only a quantitative one. From tens of places where /usr/local is currently literally used in our source tree to tens plus 1 where a macro is used for this purpose. You have to rebuild after patching tens of locations for a modified LOCALBASE right now. I'm making it easier, not harder, to overcome the issues caused by the intrusion of references to /usr/local into our base system. And as I have explained in another port to this thread, that while it is possible to introduce dynamically changed (by environment variable or sysctl variable) LOCALBASE values into the base system, the security implications could be severe. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25230c39-fc65-ec95-58e6-381f8f18a226>