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

Stefan Esser se at freebsd.org
Sun Oct 25 10:21:12 UTC 2020


Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:
>> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes <freebsd at 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:

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


More information about the svn-src-all mailing list