svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

>>>    I think that the first question we want to ask is : Do we want to
>>> support LOCALBASE being different than /usr/local
>>
>> The big majority of users will keep the default value, and I do not
>> see a good reason for a change, except if there is a large installed
>> base that traditionally uses another prefix (I have seen /vol/local
>> and /opt, but also OS and architecture-specific prefixes, for example).
> 
>   I'd still like to see some arguments for such installs.

There are no reasons, if you have a narrow scope where FreeBSD should
get installed. If it only on individual desktop users' system, they
are best served with LOCALBASE immutably fixed to /usr/local.

But there are other kinds of user and I have already given examples.
Companies that have tooling that traditionally used some other prefix
will not rewrite all their tools if we tell them that only /usr/local
is supported, for example.

I do not have to justify the existence of such use cases, and I'm happy
with /usr/local on all my systems. But I do know that such use cases
do exist and I have worked in environments where they were relevant.

>>>    I honestly don't see any advantages of making it !=/usr/local/ and
>>> before we start putting a lot of new/useless(for I guess 99% of our
>>> user base) in the tree we should here why people are using /usr/pkg or
>>> whatever weird location.
>>
>> No, why should we [assess] (assuming that word is to be implied in
>> your sentence) why people want to be able to easily use a different
>> prefix? That would be a waste of time, IMHO.
>>
>> I know that there are legitimate reasons to want a different prefix,
>> and we had requests to make it easier to support it.
> 
>   What are thoses ?

Please check the mail-lists since I did not save those messages.

>> We have literal uses of /usr/local in a lot of files in the FreeBSD
>> base system (more than 1700) and this is not going to change.
>>
>> But it was easy to replace a number of such literal pathes in base
>> system binaries, and we can make it easier for those that need a
>> different prefix to get it consistently used.
>>
>>>    If they have some good argument, then we should proceed further.
>>
>> You do not have to participate in this effort
> 
>   I do have to participate, it's a common project.

But it does not affect you if you do not use it.

>   Also since I also participate in pkg(8) and in ports/Mk lua/blah stuff
> there might be some stuff to do there so yes I need to participate.

Ports should already support PREFIX and LOCALBASE other than /usr/local.

And the pkg program even supports the LOCALBASE environment variable.

All we try to do is go away from multiple inconsistent methods and
mechanisms and make it easier for installations that do have a need
for a different LOCALBASE to get in consistently applied to all parts
of the system. (They have to go through the tree and apply local
patches to program sources or config files, currently, but will then
have the same result with much more effort spent by each of them.)

>   And since you never really started a conversation on a ml (that I know
> of) my only mean to start this participation is answering a commit
> email.

There has been a lengthy discussion in the thread about moving the
calendar data files out of the base system.

And there is review D26942, which was announced on the -current list
and which you seem to have missed. Also relevant are D27009, D27014,
and D27022, which have been mentioned in commits as far they have
already been committed, but have not been widely announced. You can
easily

>> - there are so many
>> other areas to work on (and I know you are very active in one).
> 
>   Only one ? Damn, I should work more then.

The most recent breakage you caused for me was the backlight kernel
option that has been introduced without any discussion I'm aware of.

Yes, I know about your involvement in getting support for modern GPUs
into FreeBSD and appreciate it.

>> But please do not ask those that have started to reduce the use of
>> literal /usr/local in the base system to justify this work.
> 
>   Seriously ? I have every right to ask you to justify this when it was
> not talked about in a public forum.

What is the problem with replacing a literal string with a macro that
provides the exact same string to the compiler (unless its definition
in paths.h is changed).

Why are you against Scott Long suggesting a function getlocalbase()
that can be used as the official method to have a user supplied value
of LOCALBASE become effective in a program instead of local hacks
like checking for the LOCALBASE environment variable in some programs?

This does not affect you at all, since you can continue to hard-code
/usr/local or to continue to fetch LOCALBASE from the environment.

But developers that want to make sure that a non-default value of
LOCALBASE is consistently used by their software can make use of this
function instead of inventing their own.

>> If you are happy with /usr/local, then you are not affected at all.
>> And if you need to configure your system to use a different prefix,
>> you are welcome to let us know which steps are still causing much
>> effort and should be worked on to make it easier ...
>>
>> Do you have any reason to be against removal of literal /usr/local
>> from the base system in favor of using a symbolic name for it?
> 
>   Do you have any reason to remove them at all ?

No, I do not. But I do not want to further complicate the use of a
non-default /usr/local in case it is required.

And the easiest way to do this is to provide a system-wide define
in a common include file, which already allowed you to specify e.g.
the system-wide default PATH for user programs including /usr/local/bin
and /usr/local/sbin.

Changing that path makes a different LOCALBASE effective in all programs
that have a default PATH compiled in.

The change to paths.h was just to introduce _PATH_LOCALBASE in path.h
for reference in _PATH_DEFPATH and some programs that had /usr/local as
literal strings in paths they rely on.

I really do not understand what's wrong with using a symbolic name for
a directory instead of the literal string.

And the change that started this thread makes the compiled in value of
_PATH_LOCALBASE accessible by sysctl, in the same way as the default
binary path already was as user.cs_path.

What is your problem with being able to query that value?

All of these changes have been available for review on Phabricator, but
I have not announced this particular change on -hackers.

But it has been reviewed and accepted by 2 core team members, which I
think was sufficient support to let me commit them.

Making the sysctl variable writable by root is an undocumented change
in support of the getlocalbase() function proposed by one of those
reviewers and is meant to simplify testing of such a function without
the need for a locally patched kernel. This variable is currently not
used by any program and its value therefore not relevant.

I have spent more time on this discussion than on working on the code
and I really do not understand what you are complaining about.

The changes made and still planned to the base system with regard to
LOCALBASE are not so different from the use of LOCALBASE in the ports
system, which nobody seems to object to.

Regards, STefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20201103/83b8ba72/attachment.sig>