From owner-svn-src-all@freebsd.org Tue Nov 3 10:33:22 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0A540454559; Tue, 3 Nov 2020 10:33:22 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CQR2T6Xswz3SYH; Tue, 3 Nov 2020 10:33:21 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bbc00143e0d922c7a134c.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:bc00:143e:d92:2c7a:134c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 33C881066E; Tue, 3 Nov 2020 10:33:21 +0000 (UTC) (envelope-from se@freebsd.org) To: Emmanuel Vadot Cc: Oliver Pinter , src-committers , svn-src-all , svn-src-head@freebsd.org References: <202011021848.0A2Im7Kx098921@repo.freebsd.org> <338fdfbb-6fad-0e44-5df6-b5a1c38d3e4f@freebsd.org> <20201102224907.401c9200dffba42cab827b2d@bidouilliste.com> <20201102233747.f545b6ca667d4025a3f3371b@bidouilliste.com> From: Stefan Esser Subject: Re: svn commit: r367280 - head/lib/libc/gen Message-ID: <1b636b92-92e8-4abf-0771-f7232ca6d25f@freebsd.org> Date: Tue, 3 Nov 2020 11:33:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201102233747.f545b6ca667d4025a3f3371b@bidouilliste.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nWF3ctLDblUM08QlI0CssBQPj4K2op5fi" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 10:33:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nWF3ctLDblUM08QlI0CssBQPj4K2op5fi Content-Type: multipart/mixed; boundary="bnHdc4RvExdOzlzQNCVkPQlF1bHOs4Rcr"; protected-headers="v1" From: Stefan Esser To: Emmanuel Vadot Cc: Oliver Pinter , src-committers , svn-src-all , svn-src-head@freebsd.org Message-ID: <1b636b92-92e8-4abf-0771-f7232ca6d25f@freebsd.org> Subject: Re: svn commit: r367280 - head/lib/libc/gen References: <202011021848.0A2Im7Kx098921@repo.freebsd.org> <338fdfbb-6fad-0e44-5df6-b5a1c38d3e4f@freebsd.org> <20201102224907.401c9200dffba42cab827b2d@bidouilliste.com> <20201102233747.f545b6ca667d4025a3f3371b@bidouilliste.com> In-Reply-To: <20201102233747.f545b6ca667d4025a3f3371b@bidouilliste.com> --bnHdc4RvExdOzlzQNCVkPQlF1bHOs4Rcr Content-Type: multipart/mixed; boundary="------------37EF1AE24478502182B2C699" Content-Language: en-US This is a multi-part message in MIME format. --------------37EF1AE24478502182B2C699 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable >>> 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)= =2E >=20 > 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 !=3D/usr/local/ a= nd >>> 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 o= r >>> 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. >=20 > 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 >=20 > 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 stuf= f > 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 kno= w > 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). >=20 > 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. >=20 > 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? >=20 > 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 --------------37EF1AE24478502182B2C699-- --bnHdc4RvExdOzlzQNCVkPQlF1bHOs4Rcr-- --nWF3ctLDblUM08QlI0CssBQPj4K2op5fi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAl+hMe8FAwAAAAAACgkQR+u171r99UQA SAf/cs81AsMR/MIL3nva6ELgUDElv8aN0yROGwMQ7GWwsUw0h3XBQpvxvaGWa0ptG+HjWZk+vZCy Z5KezLSsbuWsNUN7k9KIKZwnO5QYvAc8n66AKwGQI3OAedQ4B7ioJFAMpAUw98ceTWgzYHgIJIpn ayfnDy7imMU7k1Bepos3amqabPFz5jQiW2amjfwuODc4lBVrY+Pja7IsaMvN7QF4DbJPbcXPv0JT Iiy6szdwlSs3U90aldDrmYbkMsRGH30YCHRFR3XKvVTfdy/Eenm8b4tb4Upkl4XcCZBdZD0wjbx0 iNdBxxHOlKlPA/HYgKRs9Fl7V/LH5yoJNU6CDNPl1g== =6mdM -----END PGP SIGNATURE----- --nWF3ctLDblUM08QlI0CssBQPj4K2op5fi--