Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 27.10.20 um 08:37 schrieb Alex Kozlov:

On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:

So, first off, it's already hard coded. Stefan's changes change the hard
coding from 'impossible to change' to 'changeable with a recompile' which
is an improvement. It might even wind up as a build variable (or not, doing
that has some really ugly, nasty dependencies).

But even in ports-land, it's a compile time constant. Quite a large number
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...

So I'm a bit puzzled what makes this the wrong approach?

1) Making it buildtime instead of fixing a few regression cases which as
simple as reading environment variable before fallback to hardcoded /usr/local,
or make it kernel variable/sysctl if security is a concern.


Please provide patches that make the affected programs use a run-time
value for LOCALBASE (start with the base system, but do apply this to
ports that are extensions of the base system functionality to be able
to use packages on such a system with non-default LOCALBASE).

And please show that there are no security issues, that there is no
negative impact on the run-time for the huge majority of installations
that use the default value of LOCALBASE, and that there is no added
complexity to maintain such a system (starting from documentation that
needs to be adapted to a dynamically changeable LOCALBASE).

A compiled-in path is protected against manipulation by an attacker,
and, while a sysctl value could be as well, you ought to be able to
use different LOCALBASE values in jails, to make this really universal.

Please provide an architectural draft that accounts for all these points
and an estimate of the effort required to implement it and be assured
we'll openly discuss it.


2) Codifying LOCALBASE = /usr/local, so from now more people will use
it because it's in defines.


No, the _PATH_LOCALBASE makes it easier to refer to port provided files
*without* hard-coding /usr/local!

But LOCALBASE == /usr/local has been the default for so many decades
that I cannot remember when it started. Probably before BSD-4.2 already,
but we have committers that don't have to guess but have been there ;-)
(I've been a BSD user starting with BSD-4.2, and we have already used
/usr/local for the programs distributed over USENET at that time ...)

A verbatim /usr/local occurs in more than 1700 individual files in base,
and I'm going to remove some 20 of them that get compiled into binaries.

You are welcome to bring this number further down and we are awaiting
your patches.

We do not move base components to ports for fun, but to be able to
disconnect them from the release cycle, to ease outside contributions,
and to reduce the maintenance effort for release-agnostic components
(no need to MFC updates to the calendar files, for example).

And we have to compare the effort caused for the project with the effort
it takes to make FreeBSD use a non-default LOCALBASE for users that
really need it. Those will probably have forked off their own repository
to be able to make much bigger changes to the code base - adjusting the
_PATH_LOCALBASE before building the world is really a minor effort for
them.

And we want to make such a change of LOCALBASE easier than it used to
be for a long time.

If you are affected and the above does not apply to you, then please
provide the patches you probably already have ready since you relied
on them before the introduction of _PATH_LOCALBASE.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Alex Kozlov]

On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:
> On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov  wrote:
> 
> > 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 = /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
> > >
> > > Yes, and I do not need to look that up in the handbook, having been
> > > a ports committer for 2 decades by now.
> > >
> > > > If after this commit you need to rebuild base to use non-default
> > LOCALBASE/PREFIX
> > > > it is pretty big regression and POLA.
> > >
> > > How is that any different than before?
> > >
> > > What I did is make the PATH easier to change when you rebuild base.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > > > 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.
> > >
> > > I'd hope so to get rid of many of the 1713 literal uses of /usr/local
> > > in our source tree.
> > >
> > > > > 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.
> > >
> > > Yes, I already suggested CALENDAR_HOME, but as an environment variable
> > > 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 value
> > > of LOCALBASE).
> > >
> > > 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/local
> > > but can be overridden by passing LOCALBASE to the compiler (from the
> > > build infrastructure) when paths.h is included.
> > >
> > > Instead of referring to _PATH_LOCALBASE these files could directly use
> > > LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
> > > think it is best to follow this precedent.
> > >
> > > > > But then I think a CALENDAR_HOME variable would be even more useful,
> > > > > since it would allow to search an additional user selected directory
> > > > > (and not just share/calendar within what you provide as LOCALBASE).
> > >
> > > 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).
> > >
> > > 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 for
> > the record, I think that hardcoding LOCALBASE and requiring base rebuild
> > to change it is a very wrong approach.
> >
> 
> So, first off, it's already hard coded. Stefan's changes change the hard
> coding from 'impossible to change' to 'changeable with a recompile' which
> is an improvement. It might even wind up as a build variable (or not, doing
> that has some 

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 26.10.20 um 09:08 schrieb Baptiste Daroussin:

On Mon, Oct 26, 2020 at 02:05:28AM -0600, Scott Long wrote:



On Oct 26, 2020, at 1:50 AM, Baptiste Daroussin  wrote:

On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:

[...]

So, first off, it's already hard coded. Stefan's changes change the hard
coding from 'impossible to change' to 'changeable with a recompile' which
is an improvement. It might even wind up as a build variable (or not, doing
that has some really ugly, nasty dependencies).

But even in ports-land, it's a compile time constant. Quite a large number
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...

So I'm a bit puzzled what makes this the wrong approach?



I think what Alex revents to is the following:

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 LOCALBASE env
var:
- usr.sbin/pkg
- mailwrapper

which means with a prebuilt base I can still rebuild all my packages with a
different localbase and it will work with only a few configurations changes.
which imho is a good target.

The list of tools which hardcodes /usr/local
- calendar
- fortune
- cron
- bsnmp
- nvmecontrol
- cpucontrol (at least can be workaround via -d option)




It would be pretty trivial to add a new libc function, something like 
getlocaldir.2,
that took care of searching the environment and the invoking a fallback to the
compile-time default from path.h.  I’ll 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.


I'm not opposed to having such a function, but please make sure we do
not open a security loop-hole.

If there was a mechanism that allows the effective LOCALBASE to be set
in a systctl variable, we could expect the valzue to be trustworthy.

If the LOCALBASE setting was provided in an environment variable, I'd
expect at the least, that the full path up to the root directory was
sanity checked (not writable by a non-priviledged account, for example).

Else I might be able to mislead a program that accesses a configuration
file in LOCALBASE that is under control of a privileged account to use
my version of the file.

A library function that provides the value of LOCALBASE should probably
recognize being invoked in a SUID program, but I guess we need quite a
number of extra safe-guards to avoid opening up gaping security holes.

Regards, STefan

PS: I consider work on a dynamic LOCALBASE orthogonal to the proposed
replacement of verbatim uses of /usr/local by _PATH_LOCALBASE.
Please let me know if you disagree and think that the proposed
change should not be applied for this reason.
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

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 +, 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
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Baptiste Daroussin]

On Mon, Oct 26, 2020 at 02:05:28AM -0600, Scott Long wrote:
> 
> > On Oct 26, 2020, at 1:50 AM, Baptiste Daroussin  wrote:
> > 
> > On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:
> >> On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov  wrote:
> >> 
> >>> 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 = /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
>  
>  Yes, and I do not need to look that up in the handbook, having been
>  a ports committer for 2 decades by now.
>  
> > If after this commit you need to rebuild base to use non-default
> >>> LOCALBASE/PREFIX
> > it is pretty big regression and POLA.
>  
>  How is that any different than before?
>  
>  What I did is make the PATH easier to change when you rebuild base.
>  
>  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.
>  
>  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.
>  
> >> 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.
>  
>  I'd hope so to get rid of many of the 1713 literal uses of /usr/local
>  in our source tree.
>  
> >> 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.
>  
>  Yes, I already suggested CALENDAR_HOME, but as an environment variable
>  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 value
>  of LOCALBASE).
>  
>  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/local
>  but can be overridden by passing LOCALBASE to the compiler (from the
>  build infrastructure) when paths.h is included.
>  
>  Instead of referring to _PATH_LOCALBASE these files could directly use
>  LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
>  think it is best to follow this precedent.
>  
> >> But then I think a CALENDAR_HOME variable would be even more useful,
> >> since it would allow to search an additional user selected directory
> >> (and not just share/calendar within what you provide as LOCALBASE).
>  
>  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).
>  
>  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 for
> >>> the record, I think that hardcoding LOCALBASE and requiring base rebuild
> >>> to change it is a very wrong approach.
> >>> 
> >> 
> >> So, first off, it's already hard 

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Scott Long]

> On Oct 26, 2020, at 1:50 AM, Baptiste Daroussin  wrote:
> 
> On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:
>> On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov  wrote:
>> 
>>> 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 = /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
 
 Yes, and I do not need to look that up in the handbook, having been
 a ports committer for 2 decades by now.
 
> If after this commit you need to rebuild base to use non-default
>>> LOCALBASE/PREFIX
> it is pretty big regression and POLA.
 
 How is that any different than before?
 
 What I did is make the PATH easier to change when you rebuild base.
 
 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.
 
 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.
 
>> 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.
 
 I'd hope so to get rid of many of the 1713 literal uses of /usr/local
 in our source tree.
 
>> 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.
 
 Yes, I already suggested CALENDAR_HOME, but as an environment variable
 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 value
 of LOCALBASE).
 
 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/local
 but can be overridden by passing LOCALBASE to the compiler (from the
 build infrastructure) when paths.h is included.
 
 Instead of referring to _PATH_LOCALBASE these files could directly use
 LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
 think it is best to follow this precedent.
 
>> But then I think a CALENDAR_HOME variable would be even more useful,
>> since it would allow to search an additional user selected directory
>> (and not just share/calendar within what you provide as LOCALBASE).
 
 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).
 
 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 for
>>> the record, I think that hardcoding LOCALBASE and requiring base rebuild
>>> to change it is a very wrong approach.
>>> 
>> 
>> So, first off, it's already hard coded. Stefan's changes change the hard
>> coding from 'impossible to change' to 'changeable with a recompile' which
>> is an improvement. It might even wind up as a build variable (or not, doing
>> that has some really ugly, nasty dependencies).
>> 
>> But 

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Baptiste Daroussin]

On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:
> On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov  wrote:
> 
> > 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 = /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
> > >
> > > Yes, and I do not need to look that up in the handbook, having been
> > > a ports committer for 2 decades by now.
> > >
> > > > If after this commit you need to rebuild base to use non-default
> > LOCALBASE/PREFIX
> > > > it is pretty big regression and POLA.
> > >
> > > How is that any different than before?
> > >
> > > What I did is make the PATH easier to change when you rebuild base.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > > > 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.
> > >
> > > I'd hope so to get rid of many of the 1713 literal uses of /usr/local
> > > in our source tree.
> > >
> > > > > 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.
> > >
> > > Yes, I already suggested CALENDAR_HOME, but as an environment variable
> > > 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 value
> > > of LOCALBASE).
> > >
> > > 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/local
> > > but can be overridden by passing LOCALBASE to the compiler (from the
> > > build infrastructure) when paths.h is included.
> > >
> > > Instead of referring to _PATH_LOCALBASE these files could directly use
> > > LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
> > > think it is best to follow this precedent.
> > >
> > > > > But then I think a CALENDAR_HOME variable would be even more useful,
> > > > > since it would allow to search an additional user selected directory
> > > > > (and not just share/calendar within what you provide as LOCALBASE).
> > >
> > > 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).
> > >
> > > 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 for
> > the record, I think that hardcoding LOCALBASE and requiring base rebuild
> > to change it is a very wrong approach.
> >
> 
> So, first off, it's already hard coded. Stefan's changes change the hard
> coding from 'impossible to change' to 'changeable with a recompile' which
> is an improvement. It might even wind up as a build variable (or not, doing
> that has some 

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Warner Losh]

On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov  wrote:

> 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 = /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
> >
> > Yes, and I do not need to look that up in the handbook, having been
> > a ports committer for 2 decades by now.
> >
> > > If after this commit you need to rebuild base to use non-default
> LOCALBASE/PREFIX
> > > it is pretty big regression and POLA.
> >
> > How is that any different than before?
> >
> > What I did is make the PATH easier to change when you rebuild base.
> >
> > 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.
> >
> > 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.
> >
> > > > 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.
> >
> > I'd hope so to get rid of many of the 1713 literal uses of /usr/local
> > in our source tree.
> >
> > > > 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.
> >
> > Yes, I already suggested CALENDAR_HOME, but as an environment variable
> > 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 value
> > of LOCALBASE).
> >
> > 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/local
> > but can be overridden by passing LOCALBASE to the compiler (from the
> > build infrastructure) when paths.h is included.
> >
> > Instead of referring to _PATH_LOCALBASE these files could directly use
> > LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
> > think it is best to follow this precedent.
> >
> > > > But then I think a CALENDAR_HOME variable would be even more useful,
> > > > since it would allow to search an additional user selected directory
> > > > (and not just share/calendar within what you provide as LOCALBASE).
> >
> > 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).
> >
> > 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 for
> the record, I think that hardcoding LOCALBASE and requiring base rebuild
> to change it is a very wrong approach.
>

So, first off, it's already hard coded. Stefan's changes change the hard
coding from 'impossible to change' to 'changeable with a recompile' which
is an improvement. It might even wind up as a build variable (or not, doing
that has some really ugly, nasty dependencies).

But even in ports-land, it's a compile time constant. Quite a large number
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...

So I'm a bit 

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Alex Kozlov]

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 = /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
> 
> Yes, and I do not need to look that up in the handbook, having been
> a ports committer for 2 decades by now.
> 
> > If after this commit you need to rebuild base to use non-default 
> > LOCALBASE/PREFIX
> > it is pretty big regression and POLA.
> 
> How is that any different than before?
> 
> What I did is make the PATH easier to change when you rebuild base.
> 
> 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.
> 
> 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.
> 
> > > 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.
> 
> I'd hope so to get rid of many of the 1713 literal uses of /usr/local
> in our source tree.
> 
> > > 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.
> 
> Yes, I already suggested CALENDAR_HOME, but as an environment variable
> 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 value
> of LOCALBASE).
> 
> 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/local
> but can be overridden by passing LOCALBASE to the compiler (from the
> build infrastructure) when paths.h is included.
> 
> Instead of referring to _PATH_LOCALBASE these files could directly use
> LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
> think it is best to follow this precedent.
> 
> > > But then I think a CALENDAR_HOME variable would be even more useful,
> > > since it would allow to search an additional user selected directory
> > > (and not just share/calendar within what you provide as LOCALBASE).
> 
> 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).
> 
> 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 for
the record, I think that hardcoding LOCALBASE and requiring base rebuild
to change it is a very wrong approach.


-- 
Alex
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[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 +, 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".

> 
> 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...
  
> > 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.

>  
> > 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.
>  
> > But then I think a CALENDAR_HOME variable would be even more useful,
> > since it would allow to search an additional user selected directory
> > (and not just share/calendar within what you provide as LOCALBASE).
> > 
> > Regards, STefan
> > 
> > PS: If you are a source committer, you might even commit such a
> > change yourself. But I'd think it should be reviewed, and it
> > might be a good idea to wait until other changes (e.g. the
> > switch-over to port-supplied calendar files) have been worked
> > out.
> 
> 
> -- 
> Alex
> 

-- 
Rod Grimes rgri...@freebsd.org
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Warner Losh]

On Sun, Oct 25, 2020, 9:04 AM Kyle Evans  wrote:

> On Sun, Oct 25, 2020 at 5:21 AM Stefan Esser  wrote:
> >
> > Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:
> > >> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes <
> free...@gndrsh.dnsmgr.net>
> > >> wrote:
> >  +#define  _PATH_LOCALBASE "/usr/local"
> >  +
> > >>>
> > >>> Something feels very wrong about this becoming a  defined path in
> base,
> > >>> it is further dependence on /usr/local which in the early days we
> spent
> > >>> a great deal of time removing.
> > >>>
> > >>> I believe the whole ports system allows this to be something other
> > >>> than /usr/local.  Package should also allow it to be some other
> place.
> > >>>
> > >>
> > >> This removes a couple of instances of /usr/local being hardcoded and
> > >> replaces with a define, so net it's better.
> > >
> > > No, its net worse as it now creates a define that is highly likely
> > > to propogate adding additional dependencies on this value.
> > >
> > >>
> > >> It could be even better, but this is slightly better than it was
> before.
> > >
> > > I disagree, as it is now easier for additional contamination of
> > > the base system.
> >
> > There already are places that hard-code /usr/local, and I do agree
> > that this is architecturally bad, if you want to keep the base system
> > and ports as independent from each other as possible.
> >
> > But I do disagree that this was worse than before, and I'd even consider
> > replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
> > in our sources (but not introduce new references to LOCALBASE in base).
> >
> > This would simplify a grep for such source files, for example, and also
> > to build base for systems with modified LOCALBASE.
> >
> > The following C header files in base (ignoring contrib) contain the
> > string /usr/local:
> >
> > ...
> > sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
> > ...
>
> I see that you've excluded sys/contrib from the initial review, but I
> would not bother with luaconf.h in particular. These definitions just
> come from a stock Lua 5.2 and are not used in a ZFS context, they've
> ripped out loadlib and anything else that could try.
>

As an aside: I looked at using this Lua for the boot loader, but quickly
found that it was no good for that purpose due to changes like that. And it
was too far hacked from 5.2 to try to update easily...

Warner

Thanks,
>
> Kyle Evans
>
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Kyle Evans]

On Sun, Oct 25, 2020 at 5:21 AM Stefan Esser  wrote:
>
> Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:
> >> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
> >> 
> >> wrote:
>  +#define  _PATH_LOCALBASE "/usr/local"
>  +
> >>>
> >>> Something feels very wrong about this becoming a  defined path in base,
> >>> it is further dependence on /usr/local which in the early days we spent
> >>> a great deal of time removing.
> >>>
> >>> I believe the whole ports system allows this to be something other
> >>> than /usr/local.  Package should also allow it to be some other place.
> >>>
> >>
> >> This removes a couple of instances of /usr/local being hardcoded and
> >> replaces with a define, so net it's better.
> >
> > No, its net worse as it now creates a define that is highly likely
> > to propogate adding additional dependencies on this value.
> >
> >>
> >> It could be even better, but this is slightly better than it was before.
> >
> > I disagree, as it is now easier for additional contamination of
> > the base system.
>
> There already are places that hard-code /usr/local, and I do agree
> that this is architecturally bad, if you want to keep the base system
> and ports as independent from each other as possible.
>
> But I do disagree that this was worse than before, and I'd even consider
> replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
> in our sources (but not introduce new references to LOCALBASE in base).
>
> This would simplify a grep for such source files, for example, and also
> to build base for systems with modified LOCALBASE.
>
> The following C header files in base (ignoring contrib) contain the
> string /usr/local:
>
> ...
> sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
> ...

I see that you've excluded sys/contrib from the initial review, but I
would not bother with luaconf.h in particular. These definitions just
come from a stock Lua 5.2 and are not used in a ZFS context, they've
ripped out loadlib and anything else that could try.

Thanks,

Kyle Evans
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

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 = /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


Yes, and I do not need to look that up in the handbook, having been
a ports committer for 2 decades by now.


If after this commit you need to rebuild base to use non-default 
LOCALBASE/PREFIX
it is pretty big regression and POLA.


How is that any different than before?

What I did is make the PATH easier to change when you rebuild base.

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.

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.


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.


I'd hope so to get rid of many of the 1713 literal uses of /usr/local
in our source tree.


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.


Yes, I already suggested CALENDAR_HOME, but as an environment variable
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 value
of LOCALBASE).

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/local
but can be overridden by passing LOCALBASE to the compiler (from the
build infrastructure) when paths.h is included.

Instead of referring to _PATH_LOCALBASE these files could directly use
LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
think it is best to follow this precedent.


But then I think a CALENDAR_HOME variable would be even more useful,
since it would allow to search an additional user selected directory
(and not just share/calendar within what you provide as LOCALBASE).


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).

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.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:

On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
wrote:

+#define  _PATH_LOCALBASE "/usr/local"
+


Something feels very wrong about this becoming a  defined path in base,
it is further dependence on /usr/local which in the early days we spent
a great deal of time removing.

I believe the whole ports system allows this to be something other
than /usr/local.  Package should also allow it to be some other place.



This removes a couple of instances of /usr/local being hardcoded and
replaces with a define, so net it's better.


No, its net worse as it now creates a define that is highly likely
to propogate adding additional dependencies on this value.



It could be even better, but this is slightly better than it was before.


I disagree, as it is now easier for additional contamination of
the base system.


There already are places that hard-code /usr/local, and I do agree
that this is architecturally bad, if you want to keep the base system
and ports as independent from each other as possible.

But I do disagree that this was worse than before, and I'd even consider
replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
in our sources (but not introduce new references to LOCALBASE in base).

This would simplify a grep for such source files, for example, and also
to build base for systems with modified LOCALBASE.

The following C header files in base (ignoring contrib) contain the
string /usr/local:

crypto/openssh/pathnames.h
sys/sys/imgact_binmisc.h
sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
usr.bin/fortune/fortune/pathnames.h
usr.bin/mail/pathnames.h
usr.sbin/cron/cron/pathnames.h
usr.sbin/pkg/config.h
usr.sbin/pciconf/pathnames.h
usr.sbin/pciconf-xo/pathnames.h

These are C source files that include that string:

crypto/openssh/ssh-agent.c
crypto/openssh/regress/unittests/sshkey/test_sshkey.c
lib/libfetch/common.c
lib/libc/rpc/getnetconfig.c
lib/libc/nls/msgcat.c
sbin/nvmecontrol/nvmecontrol.c
sys/contrib/openzfs/cmd/zpool/zpool_main.c (FreeBSD specific?)
tools/tools/ath/athprom/athprom.c
tools/tools/net80211/wesside/wesside/wesside.c
usr.bin/env/envopts.c
usr.sbin/bsnmpd/tools/libbsnmptools/bsnmpimport.c
usr.sbin/mailwrapper/mailwrapper.c
usr.sbin/cpucontrol/cpucontrol.c

I intend to prepare a review top make them use _PATH_LOCALBASE instead.
(There might be sources under contrib that have no external up-stream
anymore, but I have not made an attempt to identify them, yet.)

There are 67 man-pages (excluding contrib) that mention /usr/local
and they will not be covered by this C macro definition.

There are further references to /usr/local, e.g. in 32 shell scripts
(outside contrib).

The next step could be to use the LOCALBASE variable that is defined
in Makefile.inc1 to provide the value used to define _PATH_LOCALBASE
in paths.h. This make variable is currently not used in bsd.prog.mk,
but it easily could, allowing to override the value used to build
the world in make.conf.

But I'd suggest to go step by step, and the first step that I suggest
(and am willing to work on) is to remove as many literal uses of
/usr/local in C sources in base (excluding contrib) as reasonable.

Maybe we should have some documentation about building the world for
systems with non-default LOCALBASE ...

Regards, STefan
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[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:
> > On Fri, Oct 23, 2020 at 09:22:23AM +, 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

If after this commit you need to rebuild base to use non-default 
LOCALBASE/PREFIX
it is pretty big regression and POLA.
 
> 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.
 
> 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.
 
> But then I think a CALENDAR_HOME variable would be even more useful,
> since it would allow to search an additional user selected directory
> (and not just share/calendar within what you provide as LOCALBASE).
> 
> Regards, STefan
> 
> PS: If you are a source committer, you might even commit such a
> change yourself. But I'd think it should be reviewed, and it
> might be a good idea to wait until other changes (e.g. the
> switch-over to port-supplied calendar files) have been worked
> out.


-- 
Alex
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Scott Long]

> On Oct 24, 2020, at 9:46 PM, Rodney W. Grimes  
> wrote:
> 
>>> 
>>> Something feels very wrong about this becoming a  defined path in base,
>>> it is further dependence on /usr/local which in the early days we spent
>>> a great deal of time removing.
>>> 
>>> I believe the whole ports system allows this to be something other
>>> than /usr/local.  Package should also allow it to be some other place.
>>> 
>> 
>> This removes a couple of instances of /usr/local being hardcoded and
>> replaces with a define, so net it's better.
> 
> No, its net worse as it now creates a define that is highly likely
> to propogate adding additional dependencies on this value.
> 

You said a bunch of words, but I have no idea what you are trying to
accomplish or what action can be taken.

>> 
>> It could be even better, but this is slightly better than it was before.
> 
> I disagree, as it is now easier for additional contamination of
> the base system.
> 

Disagreement without action is a waste of time.

Stefan proposed this change several days ago to the arch mailing list, and I
view it as a good first step to the end goal of making the cal system more
flexible and less dependent on a data source that’s fixed in place.  It’ll 
likely
evolve more over time, as software projects do.  Simply arguing that you
disagree with it or with the people involved doesn’t help this process.  Please
consider ways to be more productive in your communication.  As with others
recently, you are coming across as being obstructing as disagreeable.

Scott

___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Rodney W. Grimes]

> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > 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.
> > >
> > >   Reviewed by:imp, pfg
> > >   Differential Revision:  https://reviews.freebsd.org/D26882
> > >
> > > Modified:
> > >   head/include/paths.h
> > >   head/usr.bin/calendar/io.c
> > >   head/usr.bin/calendar/pathnames.h
> > >
> > > Modified: head/include/paths.h
> > >
> > ==
> > > --- head/include/paths.h  Fri Oct 23 08:44:53 2020(r366961)
> > > +++ head/include/paths.h  Fri Oct 23 09:22:23 2020(r366962)
> > > @@ -37,8 +37,11 @@
> > >
> > >  #include 
> > >
> > > +#define  _PATH_LOCALBASE "/usr/local"
> > > +
> >
> > Something feels very wrong about this becoming a  defined path in base,
> > it is further dependence on /usr/local which in the early days we spent
> > a great deal of time removing.
> >
> > I believe the whole ports system allows this to be something other
> > than /usr/local.  Package should also allow it to be some other place.
> >
> 
> This removes a couple of instances of /usr/local being hardcoded and
> replaces with a define, so net it's better.

No, its net worse as it now creates a define that is highly likely
to propogate adding additional dependencies on this value.

> 
> It could be even better, but this is slightly better than it was before.

I disagree, as it is now easier for additional contamination of
the base system.

> Warner
> 
> 
> > >  /* Default search path. */
> > > -#define  _PATH_DEFPATH
> >  "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
> > > +#define  _PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
> > > + _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"
> > >  /* All standard utilities path. */
> > >  #define  _PATH_STDPATH   "/usr/bin:/bin:/usr/sbin:/sbin"
> > >  /* Locate system binaries. */
> > >
> > > Modified: head/usr.bin/calendar/io.c
> > >
> > ==
> > > --- head/usr.bin/calendar/io.cFri Oct 23 08:44:53 2020
> > (r366961)
> > > +++ head/usr.bin/calendar/io.cFri Oct 23 09:22:23 2020
> > (r366962)
> > > @@ -71,7 +71,7 @@ enum {
> > >  };
> > >
> > >  const char *calendarFile = "calendar";   /* default calendar file */
> > > -static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /*
> > HOME */
> > > +static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE_LOCAL,
> > _PATH_INCLUDE}; /* HOME */
> > >  static const char *calendarNoMail = "nomail";/* don't sent mail if file
> > exist */
> > >
> > >  static char path[MAXPATHLEN];
> > >
> > > Modified: head/usr.bin/calendar/pathnames.h
> > >
> > ==
> > > --- head/usr.bin/calendar/pathnames.h Fri Oct 23 08:44:53 2020
> > (r366961)
> > > +++ head/usr.bin/calendar/pathnames.h Fri Oct 23 09:22:23 2020
> > (r366962)
> > > @@ -35,3 +35,4 @@
> > >  #include 
> > >
> > >  #define  _PATH_INCLUDE   "/usr/share/calendar"
> > > +#define  _PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar"
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
Rod Grimes rgri...@freebsd.org
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Warner Losh]

On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > 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.
> >
> >   Reviewed by:imp, pfg
> >   Differential Revision:  https://reviews.freebsd.org/D26882
> >
> > Modified:
> >   head/include/paths.h
> >   head/usr.bin/calendar/io.c
> >   head/usr.bin/calendar/pathnames.h
> >
> > Modified: head/include/paths.h
> >
> ==
> > --- head/include/paths.h  Fri Oct 23 08:44:53 2020(r366961)
> > +++ head/include/paths.h  Fri Oct 23 09:22:23 2020(r366962)
> > @@ -37,8 +37,11 @@
> >
> >  #include 
> >
> > +#define  _PATH_LOCALBASE "/usr/local"
> > +
>
> Something feels very wrong about this becoming a  defined path in base,
> it is further dependence on /usr/local which in the early days we spent
> a great deal of time removing.
>
> I believe the whole ports system allows this to be something other
> than /usr/local.  Package should also allow it to be some other place.
>

This removes a couple of instances of /usr/local being hardcoded and
replaces with a define, so net it's better.

It could be even better, but this is slightly better than it was before.

Warner


> >  /* Default search path. */
> > -#define  _PATH_DEFPATH
>  "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
> > +#define  _PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
> > + _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"
> >  /* All standard utilities path. */
> >  #define  _PATH_STDPATH   "/usr/bin:/bin:/usr/sbin:/sbin"
> >  /* Locate system binaries. */
> >
> > Modified: head/usr.bin/calendar/io.c
> >
> ==
> > --- head/usr.bin/calendar/io.cFri Oct 23 08:44:53 2020
> (r366961)
> > +++ head/usr.bin/calendar/io.cFri Oct 23 09:22:23 2020
> (r366962)
> > @@ -71,7 +71,7 @@ enum {
> >  };
> >
> >  const char *calendarFile = "calendar";   /* default calendar file */
> > -static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /*
> HOME */
> > +static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE_LOCAL,
> _PATH_INCLUDE}; /* HOME */
> >  static const char *calendarNoMail = "nomail";/* don't sent mail if file
> exist */
> >
> >  static char path[MAXPATHLEN];
> >
> > Modified: head/usr.bin/calendar/pathnames.h
> >
> ==
> > --- head/usr.bin/calendar/pathnames.h Fri Oct 23 08:44:53 2020
> (r366961)
> > +++ head/usr.bin/calendar/pathnames.h Fri Oct 23 09:22:23 2020
> (r366962)
> > @@ -35,3 +35,4 @@
> >  #include 
> >
> >  #define  _PATH_INCLUDE   "/usr/share/calendar"
> > +#define  _PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar"
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> 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.
>   
>   Reviewed by:imp, pfg
>   Differential Revision:  https://reviews.freebsd.org/D26882
> 
> Modified:
>   head/include/paths.h
>   head/usr.bin/calendar/io.c
>   head/usr.bin/calendar/pathnames.h
> 
> Modified: head/include/paths.h
> ==
> --- head/include/paths.h  Fri Oct 23 08:44:53 2020(r366961)
> +++ head/include/paths.h  Fri Oct 23 09:22:23 2020(r366962)
> @@ -37,8 +37,11 @@
>  
>  #include 
>  
> +#define  _PATH_LOCALBASE "/usr/local"
> +

Something feels very wrong about this becoming a  defined path in base,
it is further dependence on /usr/local which in the early days we spent
a great deal of time removing.

I believe the whole ports system allows this to be something other
than /usr/local.  Package should also allow it to be some other place.

>  /* Default search path. */
> -#define  _PATH_DEFPATH   
> "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
> +#define  _PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
> + _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"
>  /* All standard utilities path. */
>  #define  _PATH_STDPATH   "/usr/bin:/bin:/usr/sbin:/sbin"
>  /* Locate system binaries. */
> 
> Modified: head/usr.bin/calendar/io.c
> ==
> --- head/usr.bin/calendar/io.cFri Oct 23 08:44:53 2020
> (r366961)
> +++ head/usr.bin/calendar/io.cFri Oct 23 09:22:23 2020
> (r366962)
> @@ -71,7 +71,7 @@ enum {
>  };
>  
>  const char *calendarFile = "calendar";   /* default calendar file */
> -static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /* HOME */
> +static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE_LOCAL, 
> _PATH_INCLUDE}; /* HOME */
>  static const char *calendarNoMail = "nomail";/* don't sent mail if file 
> exist */
>  
>  static char path[MAXPATHLEN];
> 
> Modified: head/usr.bin/calendar/pathnames.h
> ==
> --- head/usr.bin/calendar/pathnames.h Fri Oct 23 08:44:53 2020
> (r366961)
> +++ head/usr.bin/calendar/pathnames.h Fri Oct 23 09:22:23 2020
> (r366962)
> @@ -35,3 +35,4 @@
>  #include 
>  
>  #define  _PATH_INCLUDE   "/usr/share/calendar"
> +#define  _PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
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"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 24.10.20 um 09:48 schrieb Alex Kozlov:

On Fri, Oct 23, 2020 at 09:22:23AM +, 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.

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.

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.

But then I think a CALENDAR_HOME variable would be even more useful,
since it would allow to search an additional user selected directory
(and not just share/calendar within what you provide as LOCALBASE).

Regards, STefan

PS: If you are a source committer, you might even commit such a
change yourself. But I'd think it should be reviewed, and it
might be a good idea to wait until other changes (e.g. the
switch-over to port-supplied calendar files) have been worked
out.


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Alex Kozlov]

On Fri, Oct 23, 2020 at 09:22:23AM +, 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.

>   Reviewed by:imp, pfg
>   Differential Revision:  https://reviews.freebsd.org/D26882
> 
> Modified:
>   head/include/paths.h
>   head/usr.bin/calendar/io.c
>   head/usr.bin/calendar/pathnames.h
> 
> Modified: head/include/paths.h
> ==
> --- head/include/paths.h  Fri Oct 23 08:44:53 2020(r366961)
> +++ head/include/paths.h  Fri Oct 23 09:22:23 2020(r366962)
> @@ -37,8 +37,11 @@
>  
>  #include 
>  
> +#define  _PATH_LOCALBASE "/usr/local"
> +
>  /* Default search path. */
> -#define  _PATH_DEFPATH   
> "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
> +#define  _PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
> + _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"


-- 
Alex
___
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"

svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Eßer]

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.
  
  Reviewed by:  imp, pfg
  Differential Revision:https://reviews.freebsd.org/D26882

Modified:
  head/include/paths.h
  head/usr.bin/calendar/io.c
  head/usr.bin/calendar/pathnames.h

Modified: head/include/paths.h
==
--- head/include/paths.hFri Oct 23 08:44:53 2020(r366961)
+++ head/include/paths.hFri Oct 23 09:22:23 2020(r366962)
@@ -37,8 +37,11 @@
 
 #include 
 
+#define_PATH_LOCALBASE "/usr/local"
+
 /* Default search path. */
-#define_PATH_DEFPATH   
"/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
+#define_PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
+   _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"
 /* All standard utilities path. */
 #define_PATH_STDPATH   "/usr/bin:/bin:/usr/sbin:/sbin"
 /* Locate system binaries. */

Modified: head/usr.bin/calendar/io.c
==
--- head/usr.bin/calendar/io.c  Fri Oct 23 08:44:53 2020(r366961)
+++ head/usr.bin/calendar/io.c  Fri Oct 23 09:22:23 2020(r366962)
@@ -71,7 +71,7 @@ enum {
 };
 
 const char *calendarFile = "calendar"; /* default calendar file */
-static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /* HOME */
+static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE_LOCAL, 
_PATH_INCLUDE}; /* HOME */
 static const char *calendarNoMail = "nomail";/* don't sent mail if file exist 
*/
 
 static char path[MAXPATHLEN];

Modified: head/usr.bin/calendar/pathnames.h
==
--- head/usr.bin/calendar/pathnames.h   Fri Oct 23 08:44:53 2020
(r366961)
+++ head/usr.bin/calendar/pathnames.h   Fri Oct 23 09:22:23 2020
(r366962)
@@ -35,3 +35,4 @@
 #include 
 
 #define_PATH_INCLUDE   "/usr/share/calendar"
+#define_PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar"
___
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"