Date: Mon, 26 Oct 2020 09:08:03 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: Warner Losh <imp@bsdimp.com>, Alex Kozlov <ak@freebsd.org>, Stefan Esser <se@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r366962 - in head: include usr.bin/calendar Message-ID: <20201026080803.7h76fkrfwv4dhp4w@ivaldir.net> In-Reply-To: <8242C5E5-0F9E-4C17-BDBF-1926AF580325@samsco.org> References: <202010230922.09N9MNZu040921@repo.freebsd.org> <20201024074840.GA26119@ravenloft.kiev.ua> <38d15142-1cb1-eb1f-215e-cee165743d99@freebsd.org> <20201025055633.GA52119@ravenloft.kiev.ua> <0140ae63-3044-9946-4047-c64331be0b50@freebsd.org> <20201026060038.GA78455@ravenloft.kiev.ua> <CANCZdfqHT=pYh9Roe2pvVHbTMHectjVwwv4HPU5jrUOORpKY8w@mail.gmail.com> <20201026075057.rbiwxbinzpkhh2tp@ivaldir.net> <8242C5E5-0F9E-4C17-BDBF-1926AF580325@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--fkne256ocxnezvrm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 26, 2020 at 02:05:28AM -0600, Scott Long wrote: >=20 > > On Oct 26, 2020, at 1:50 AM, Baptiste Daroussin <bapt@FreeBSD.org> wrot= e: > >=20 > > On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote: > >> On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov <ak@freebsd.org> wrote: > >>=20 > >>> On Sun, Oct 25, 2020 at 11:37:34AM +0100, Stefan Esser wrote: > >>>> Am 25.10.20 um 06:56 schrieb Alex Kozlov: > >>>>> On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote: > >>>>>> Am 24.10.20 um 09:48 schrieb Alex Kozlov: > >>>> [...] > >>>>>>> You are hardcoding assumption that LOCALBASE =3D /usr/local. Plea= se > >>> 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 ot= her > >>>>>> PREFIX, as of now). > >>>>>=20 > >>>>>> 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 !=3D LOCALBASE and both !=3D /usr/local configurations > >>>>> are supported in the ports tree and the base for a long time, please > >>> see > >>>>>=20 > >>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/po= rting-prefix.html > >>>>=20 > >>>> Yes, and I do not need to look that up in the handbook, having been > >>>> a ports committer for 2 decades by now. > >>>>=20 > >>>>> If after this commit you need to rebuild base to use non-default > >>> LOCALBASE/PREFIX > >>>>> it is pretty big regression and POLA. > >>>>=20 > >>>> How is that any different than before? > >>>>=20 > >>>> What I did is make the PATH easier to change when you rebuild base. > >>>>=20 > >>>> There are numerous programs in base that contain the literal string > >>>> /usr/local - and what I did was implement a mechanism that allows > >>>> to replace this literal reference with a simple change in paths.h. > >>>>=20 > >>>> If you do not modify paths.h for a different LOCALBASE, then you'll > >>>> get a wrong _PATH_DEFPATH compiled into your binaries, for example. > >>>>=20 > >>>>>> 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. > >>>>=20 > >>>> I'd hope so to get rid of many of the 1713 literal uses of /usr/local > >>>> in our source tree. > >>>>=20 > >>>>>> If you can show me precedence of a LOCALBASE environment variable > >>>>>> being used in the way you suggest, I'd be willing to make calendar > >>>>>> use it. > >>>>> Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME > >>>>> is a better name. > >>>>=20 > >>>> Yes, I already suggested CALENDAR_HOME, but as an environment variab= le > >>>> to check, if you want to be able to path an additional directory (or > >>>> search path) to the calendar program at run-time. But why introduce > >>>> a CALENDAR_HOME macro in the sources, if the port supplied calendar > >>>> files are known to be found at LOCALBASE/share/calendar (for some va= lue > >>>> of LOCALBASE). > >>>>=20 > >>>> I want to make more programs that currently hard-code /usr/local use > >>>> _PATH_LOCALBASE instead. This C macro can then be default to /usr/lo= cal > >>>> but can be overridden by passing LOCALBASE to the compiler (from the > >>>> build infrastructure) when paths.h is included. > >>>>=20 > >>>> Instead of referring to _PATH_LOCALBASE these files could directly u= se > >>>> LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h= I > >>>> think it is best to follow this precedent. > >>>>=20 > >>>>>> But then I think a CALENDAR_HOME variable would be even more usefu= l, > >>>>>> since it would allow to search an additional user selected directo= ry > >>>>>> (and not just share/calendar within what you provide as LOCALBASE). > >>>>=20 > >>>> My change did not add any dependency on LOCALBASE to any previously > >>>> existing functionality. It added support for calendar files provided > >>>> by a port (a feature that did not exist before) at a location that is > >>>> correct for the big majority of users (who do not modify LOCALBASE). > >>>>=20 > >>>> As I said: I'm going to make it easier to build the base system with > >>>> a different LOCALBASE, but not by run-time checking an environment > >>>> variable that specifies LOCALBASE in each affected program. > >>> It seems that you intend to follow through no matter what. So, just f= or > >>> the record, I think that hardcoding LOCALBASE and requiring base rebu= ild > >>> to change it is a very wrong approach. > >>>=20 > >>=20 > >> So, first off, it's already hard coded. Stefan's changes change the ha= rd > >> coding from 'impossible to change' to 'changeable with a recompile' wh= ich > >> is an improvement. It might even wind up as a build variable (or not, = doing > >> that has some really ugly, nasty dependencies). > >>=20 > >> But even in ports-land, it's a compile time constant. Quite a large nu= mber > >> of ports will allow you to change it at compile / build time, but not > >> after. You have to rebuild if you want to change PREFIX... > >>=20 > >> So I'm a bit puzzled what makes this the wrong approach? > >>=20 > >=20 > > I think what Alex revents to is the following: > >=20 > > Some utilities in base base either have a configurable way to look for = things in > > localbase (via configuration entries for instances): > > - syslog > > - periodic > > - rc > > - man > > Some have hardcoded LOCALBASE but only after looking first at the LOCAL= BASE env > > var: > > - usr.sbin/pkg > > - mailwrapper > >=20 > > which means with a prebuilt base I can still rebuild all my packages wi= th a > > different localbase and it will work with only a few configurations cha= nges. > > which imho is a good target. > >=20 > > The list of tools which hardcodes /usr/local > > - calendar > > - fortune > > - cron > > - bsnmp > > - nvmecontrol > > - cpucontrol (at least can be workaround via -d option) > >=20 > >=20 >=20 > It would be pretty trivial to add a new libc function, something like get= localdir.2, > that took care of searching the environment and the invoking a fallback t= o the > compile-time default from path.h. I=E2=80=99ll see if I can come up with= something for > review before I fall asleep. Exactly what I was thinking about ;) could also be a simple static inline function somewhere (path.h?) if we don= 't want to "pollute" libc. I am fine with both. Best regards, Bapt --fkne256ocxnezvrm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl+Wg+AACgkQY4mL3PG3 PlooDA//Vdu7AzQPjBSs9qvYtTUY4j7DwSCEHHg13v5CUMCB6RgDfoE/55Vx3PJN Phrn0vV+8PHHDVkk+dxWX2++zlMXoKpaZqL2JnaIkV6UxuEToD4AzIjqJe5V3E4t 8EFC/AW077Ny4CNqzD6mbRwwOwxrDXhYxMM0HzK7c1VClMIfKkr3lENtC58tr4Ba 25W0zyYEUGC65J+3POTdYqZt/7LAF3MqHeqRUGeKOXuMSVGGBAIRjR+znYuWGTT6 WEPyOvCp7/PWYXqQbqld2zNtrnn6Ch55r0I4T+DydGc2gwymcpF2jBo2bUNSvI3c OCGk4VPuh1WnTbI//BOjrn26sREn2RejhfljXfkWtcIjwvKYnNr5K7a5or3pBwyZ X9kL0BGquqSOaqtUjM5tFhy67U6r5bQgMSLHfEnnHPqLHIYEgN5S30CclMZQFMOi o/8wew0XhGoKU0b/lFXZf4r4QgfCiCKkRWTAW8OU46iGjTvQHPcovB1bz+qW+nEA 1wq+ncjeuTIwU6v6108r9V/OVWTtmUXTwbq8Hy7g8zD0HSCIz69KvOvX+g9UeM9y trqgqWI5U71zy8wuHTdKCVngN0tjMUhIxTM+vtrUmfvkuMFT8HSWKVyL9PWEygJ5 1JX5Q1TlrRomCTY0zwZYXENTKvUZkDWFqAorBCm+S/QLfRVGavw= =88yo -----END PGP SIGNATURE----- --fkne256ocxnezvrm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201026080803.7h76fkrfwv4dhp4w>