I think that the first question we want to ask is : Do we want to support LOCALBASE being different than /usr/localThe 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 effortI 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
OpenPGP_signature
Description: OpenPGP digital signature
