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

[Rodney W. Grimes]

Picking a late message in this thread to reply to....

[ Charset windows-1252 unsupported, converting... ]
> >>>    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.
> 

For 25 years PREFIX has been rigidly a part of the ports infustructure,
why is it that the BASE system has been allowed to de-evolve from this
concept as documented and REQUIRED by:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html


I again assert at one time the base system was clean of this,
it has regressed and needs to be fixed.  That fix should restore
the independence of PREFIX.  If 30k ported pieces of software can
do it why can't the base system do it?

Those ports do not require a recompile, why should the base system?

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


-- 
Rod Grimes                                                 rgrimes at freebsd.org