From owner-svn-src-head@freebsd.org Wed Nov 4 19:41:05 2020 Return-Path: Delivered-To: svn-src-head@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 13CAE464837; Wed, 4 Nov 2020 19:41:05 +0000 (UTC) (envelope-from bapt@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 4CRH806hdTz49V0; Wed, 4 Nov 2020 19:41:04 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id B0C591F602; Wed, 4 Nov 2020 19:41:04 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id E9B2BD8007; Wed, 4 Nov 2020 20:40:58 +0100 (CET) Date: Wed, 4 Nov 2020 20:40:58 +0100 From: Baptiste Daroussin To: rgrimes@freebsd.org Cc: Stefan Esser , Emmanuel Vadot , Oliver Pinter , src-committers , svn-src-all , svn-src-head@freebsd.org Subject: Re: svn commit: r367280 - head/lib/libc/gen Message-ID: <20201104194058.tbrh4vvgevbnb6pd@ivaldir.net> References: <1b636b92-92e8-4abf-0771-f7232ca6d25f@freebsd.org> <202011041904.0A4J4b5k025815@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vpbio6n3osvpq77o" Content-Disposition: inline In-Reply-To: <202011041904.0A4J4b5k025815@gndrsh.dnsmgr.net> X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:41:05 -0000 --vpbio6n3osvpq77o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 04, 2020 at 11:04:37AM -0800, Rodney W. Grimes wrote: > Picking a late message in this thread to reply to.... >=20 > [ 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 exampl= e). > > >=20 > > > I'd still like to see some arguments for such installs. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 >=20 > 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: >=20 > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/portin= g-prefix.html >=20 >=20 > 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? >=20 > Those ports do not require a recompile, why should the base system? I am just reacting on that phrase, you do really think the ports do not req= uire a rebuild to be able to relocate from a PREFIX to another? this is a myth! ports support being built with another prefix than localbase but that is al= l it supports. There has been a flase claim for years that relocating work, but beside the tools proposing the feature it never worked, or to be fait only on some very specific port. But it is just an impossible goal to achieve otherwise as for example all t= he path which gets hardcoded at build time depending on the prefix will end up= in the binary looking for resources in a hardcoded prefix at runtime and so fa= il if you relocate the package, for example its datadir. Best regards, Bapt --vpbio6n3osvpq77o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl+jA8MACgkQY4mL3PG3 PlphzxAArje0+AQZ2mS0GqEERDQe9tyAkeEo56zRAQz1UDlVBniuLZuh1dX+cPiU 5W5hK8jJ4NVBzII5Xj7RwUkjPiEd+aRhOcdRXNrTp/hAeCNVSbvXnwYR+4Q1XdFE 1hdfY14V/CRqboBOUlyBnPd9P/WG2GPBUrFC1JBW/0JGVcLp1SV97N8nDKsCeA03 Nn8QCcDVwSr5BEOMOJoDIrn8v5y9LWitjXEL2m3YlsO0V6OiCRKnKqGKxyQssvlJ c+GOUEmeAnzOuQedghIwDAt3HZj6WJmBtZ48hGjG11GteCGBVennx1NmbJHvrz8D v3jUa6RjDyZjAXgB1f0fZ7W+L23/ytTUSy0/mDC+XJ2NUXCXEhb35ZdDKo64hlP5 Itux1LPHqx8WoddwXeCQyL8E478Z1KXvVaNha+Kd3Ol0yrBob8p3UnUCTP/zEloZ W6LWN+EloOEW2gbYSbHAOLTy/a5C0UpbRLvLBZyN6SdpuE0VWBrbK1L24MI2Deyg VSsAlornaKtC8/931TwTRRicvEVd0L0AGzG7L+WYuYiPJJhHimCPfnSvIDmJDLK5 SvUwEeG4H1JoQSsjQaNRrdB9tIYhO5SiiZdv1ZAunnsvXZj2Mbvb/iRxR+/hKAv9 6W6mzkWvjlzNHsltObGwdwhtgjguwn/n5MAyklygumXwdBXiZsw= =kDWl -----END PGP SIGNATURE----- --vpbio6n3osvpq77o--