From owner-svn-src-all@freebsd.org Mon Oct 26 08:05:33 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 4ADC243E317; Mon, 26 Oct 2020 08:05:33 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKS7c2N6Vz3d47; Mon, 26 Oct 2020 08:05:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 38496938; Mon, 26 Oct 2020 04:05:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 26 Oct 2020 04:05:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=g X3agLtDrfWUlTTMO1VVT3D9T9XElRQiABkjy/AFSa0=; b=c2th8N8WGr+pLETzo juE5HNg3YYJcB3rvhgzhdcGoaOUEnFBuKb2FVlLOFK6nlnAUVcYOZyPiWqCwj7r8 cUns3u5PHBjOg9sSikevM8KMecgpTitvRKlAUNs2SlUpnISDnthl1/CKAl/ePCnF oMpf1Yq1ihs2SOkBiky9wVxJe38nK9xNQIrsKfWhGjZv1Pp9Q5iEhfCtpNLSeKOg yUEUZ6Cil6Gi3ENOHaFVXSNymtd8vL8djR9A5rrGtmdo6Ni4Iqww3rlm1AFFNFI3 0gF99NQQK6SYffv6EeEvvv4kc4B1V5/Cw7ZRdbYxIQriObMFLKBTkomSDs3gHtos nt4Eg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=gX3agLtDrfWUlTTMO1VVT3D9T9XElRQiABkjy/AFS a0=; b=UxtbJXGjM1XhDfpYTFkpwo5R71W4ai1fRQibKsvzjGSeuOUJBIda0IjK0 7drR7LVOaZHfGYfmADSdAdJ6K6bMWnV6hYmxDMY8bIL0vMVlnLfajc8yW+4EJ0Q0 o/JsZbOaqxD2GTiSVXFzVqDHFG8Nm9oFoDA/w7zgJPtdo9WZJWTrx87LUeCfitVP hbObtd/jRKoC7ZW/YW7C7QJ05Q+xYM9woNDx9RWqzuNQ1zLaw5nrrmqf4x3TvJAw FTsoOSTjE/yHiPgsNBpAwVs1o7Swm7u4tmU9AI4nXs8IRkpJeFov21o9HBwlKHjc eCbiaJuk2Qorl7X9EA4hMGmPPVWnQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeehgdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goofgvughsqdftgedtgedqtdeiucdlfedttddmnecujfgurheptggguffhjgffgffkfhfv ofesthhqmhdthhdtjeenucfhrhhomhepufgtohhtthcunfhonhhguceoshgtohhtthhlse hsrghmshgtohdrohhrgheqnecuggftrfgrthhtvghrnhepudduveekheehiedukeekleel vedufeevfeetudfgtdffteffleehheffueffgfehnecuffhomhgrihhnpehfrhgvvggssh gurdhorhhgnecukfhppeekrdegiedrkeelrddvudefnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepshgtohhtthhlsehsrghmshgtohdrohhrgh X-ME-Proxy: Received: from [192.168.0.114] (unknown [8.46.89.213]) by mail.messagingengine.com (Postfix) with ESMTPA id 090693280063; Mon, 26 Oct 2020 04:05:28 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: svn commit: r366962 - in head: include usr.bin/calendar From: Scott Long In-Reply-To: <20201026075057.rbiwxbinzpkhh2tp@ivaldir.net> Date: Mon, 26 Oct 2020 02:05:28 -0600 Cc: Warner Losh , Alex Kozlov , Stefan Esser , src-committers , svn-src-all , svn-src-head Content-Transfer-Encoding: quoted-printable Message-Id: <8242C5E5-0F9E-4C17-BDBF-1926AF580325@samsco.org> References: <202010230922.09N9MNZu040921@repo.freebsd.org> <20201024074840.GA26119@ravenloft.kiev.ua> <38d15142-1cb1-eb1f-215e-cee165743d99@freebsd.org> <20201025055633.GA52119@ravenloft.kiev.ua> <0140ae63-3044-9946-4047-c64331be0b50@freebsd.org> <20201026060038.GA78455@ravenloft.kiev.ua> <20201026075057.rbiwxbinzpkhh2tp@ivaldir.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4CKS7c2N6Vz3d47 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=samsco.org header.s=fm1 header.b=c2th8N8W; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=UxtbJXGj; dmarc=none; spf=pass (mx1.freebsd.org: domain of scottl@samsco.org designates 64.147.123.17 as permitted sender) smtp.mailfrom=scottl@samsco.org X-Spamd-Result: default: False [-3.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[samsco.org:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[scottl]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[samsco.org]; NEURAL_HAM_LONG(-1.01)[-1.007]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[samsco.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.93)[-0.927]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[svn-src-all,svn-src-head]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.17:from] 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: Mon, 26 Oct 2020 08:05:33 -0000 > On Oct 26, 2020, at 1:50 AM, Baptiste Daroussin = wrote: >=20 > On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote: >> On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov wrote: >>=20 >>> On Sun, Oct 25, 2020 at 11:37:34AM +0100, Stefan Esser wrote: >>>> Am 25.10.20 um 06:56 schrieb Alex Kozlov: >>>>> On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote: >>>>>> Am 24.10.20 um 09:48 schrieb Alex Kozlov: >>>> [...] >>>>>>> You are hardcoding assumption that LOCALBASE =3D /usr/local. = Please >>> make it >>>>>>> overridable with LOCALBASE environment variable. >>>>>> This was a trivial change to get us going with calendars provided = by >>>>>> a port (which has not been committed, yet - therefore there are = no >>>>>> port-provided calendars, neither under /usr/local nor under any = other >>>>>> PREFIX, as of now). >>>>>=20 >>>>>> I understand what you are asking for, but in such a case I'd = rather >>>>>> think you want to rebuild FreeBSD with _PATH_LOCALBASE modified = in >>>>>> paths.h. >>>>> The PREFIX !=3D LOCALBASE and both !=3D /usr/local configurations >>>>> are supported in the ports tree and the base for a long time, = please >>> see >>>>>=20 >>> = https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting= -prefix.html >>>>=20 >>>> Yes, and I do not need to look that up in the handbook, having been >>>> a ports committer for 2 decades by now. >>>>=20 >>>>> If after this commit you need to rebuild base to use non-default >>> LOCALBASE/PREFIX >>>>> it is pretty big regression and POLA. >>>>=20 >>>> How is that any different than before? >>>>=20 >>>> What I did is make the PATH easier to change when you rebuild base. >>>>=20 >>>> There are numerous programs in base that contain the literal string >>>> /usr/local - and what I did was implement a mechanism that allows >>>> to replace this literal reference with a simple change in paths.h. >>>>=20 >>>> If you do not modify paths.h for a different LOCALBASE, then you'll >>>> get a wrong _PATH_DEFPATH compiled into your binaries, for example. >>>>=20 >>>>>> And I have made this a single instance that needs to be changed. >>>>>> Before my change there were 2 instances of /usr/local hard-coded >>>>>> in _PATH_DEFPATH - now you have to only change the definition of >>>>>> _PATH_LOCALBASE to adjust all 3 locations that use it. >>>>> I think you made situation worse, there were two stray hardcoded >>>>> string and now there is official LOCALBASE define which likely = will be >>>>> used by other people in the future. >>>>=20 >>>> I'd hope so to get rid of many of the 1713 literal uses of = /usr/local >>>> in our source tree. >>>>=20 >>>>>> If you can show me precedence of a LOCALBASE environment variable >>>>>> being used in the way you suggest, I'd be willing to make = calendar >>>>>> use it. >>>>> Just an analogy from LOCALBASE make variable, perhaps = CALENDAR_HOME >>>>> is a better name. >>>>=20 >>>> Yes, I already suggested CALENDAR_HOME, but as an environment = variable >>>> to check, if you want to be able to path an additional directory = (or >>>> search path) to the calendar program at run-time. But why introduce >>>> a CALENDAR_HOME macro in the sources, if the port supplied calendar >>>> files are known to be found at LOCALBASE/share/calendar (for some = value >>>> of LOCALBASE). >>>>=20 >>>> I want to make more programs that currently hard-code /usr/local = use >>>> _PATH_LOCALBASE instead. This C macro can then be default to = /usr/local >>>> but can be overridden by passing LOCALBASE to the compiler (from = the >>>> build infrastructure) when paths.h is included. >>>>=20 >>>> Instead of referring to _PATH_LOCALBASE these files could directly = use >>>> LOCALBASE, but since other paths are defined as _PATH_xxx in = paths.h I >>>> think it is best to follow this precedent. >>>>=20 >>>>>> But then I think a CALENDAR_HOME variable would be even more = useful, >>>>>> since it would allow to search an additional user selected = directory >>>>>> (and not just share/calendar within what you provide as = LOCALBASE). >>>>=20 >>>> My change did not add any dependency on LOCALBASE to any previously >>>> existing functionality. It added support for calendar files = provided >>>> by a port (a feature that did not exist before) at a location that = is >>>> correct for the big majority of users (who do not modify = LOCALBASE). >>>>=20 >>>> As I said: I'm going to make it easier to build the base system = with >>>> a different LOCALBASE, but not by run-time checking an environment >>>> variable that specifies LOCALBASE in each affected program. >>> It seems that you intend to follow through no matter what. So, just = for >>> the record, I think that hardcoding LOCALBASE and requiring base = rebuild >>> to change it is a very wrong approach. >>>=20 >>=20 >> So, first off, it's already hard coded. Stefan's changes change the = hard >> coding from 'impossible to change' to 'changeable with a recompile' = which >> is an improvement. It might even wind up as a build variable (or not, = doing >> that has some really ugly, nasty dependencies). >>=20 >> But even in ports-land, it's a compile time constant. Quite a large = number >> of ports will allow you to change it at compile / build time, but not >> after. You have to rebuild if you want to change PREFIX... >>=20 >> So I'm a bit puzzled what makes this the wrong approach? >>=20 >=20 > I think what Alex revents to is the following: >=20 > Some utilities in base base either have a configurable way to look for = things in > localbase (via configuration entries for instances): > - syslog > - periodic > - rc > - man > Some have hardcoded LOCALBASE but only after looking first at the = LOCALBASE env > var: > - usr.sbin/pkg > - mailwrapper >=20 > which means with a prebuilt base I can still rebuild all my packages = with a > different localbase and it will work with only a few configurations = changes. > which imho is a good target. >=20 > The list of tools which hardcodes /usr/local > - calendar > - fortune > - cron > - bsnmp > - nvmecontrol > - cpucontrol (at least can be workaround via -d option) >=20 >=20 It would be pretty trivial to add a new libc function, something like = getlocaldir.2, that took care of searching the environment and the invoking a fallback = to the compile-time default from path.h. I=E2=80=99ll see if I can come up = with something for review before I fall asleep. Scott