From owner-svn-src-head@freebsd.org Mon Nov 2 22:40:49 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 0FC8045D244; Mon, 2 Nov 2020 22:40:49 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CQ7DJ06h6z46l0; Mon, 2 Nov 2020 22:40:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1604356846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Uezipp7EoVuadyGnzeDPKyRlTeHF0n+a3QpylyMInz0=; b=bfIT0T2A/9V1YQ4NGfJUDOQn9ScbNba90yM6xSw29E3pNffesxDw6UeZKXuWgSHOO4VSP2 2iDJs/hX+RSCbHdUhFKoKpuCLozdVpdh2JbsALCyBNYBQzZ4ko7u/8Y3B6jrowipOJl0gk SkAK7ZRyrqg8Oh1bRb+E2XyvUbRfn/o= Received: from amy.home (lfbn-idf2-1-288-247.w82-123.abo.wanadoo.fr [82.123.126.247]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6680a4d3 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 2 Nov 2020 22:40:46 +0000 (UTC) Date: Mon, 2 Nov 2020 23:40:45 +0100 From: Emmanuel Vadot To: Konstantin Belousov Cc: Stefan Esser , src-committers , svn-src-all , svn-src-head@freebsd.org Subject: Re: svn commit: r367280 - head/lib/libc/gen Message-Id: <20201102234045.2c932050240f040752ca066b@bidouilliste.com> In-Reply-To: <20201102223214.GO2654@kib.kiev.ua> References: <202011021848.0A2Im7Kx098921@repo.freebsd.org> <338fdfbb-6fad-0e44-5df6-b5a1c38d3e4f@freebsd.org> <20201102224907.401c9200dffba42cab827b2d@bidouilliste.com> <20201102221039.GN2654@kib.kiev.ua> <20201102232215.3ae253e0478791a3261d1dd1@bidouilliste.com> <20201102223214.GO2654@kib.kiev.ua> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CQ7DJ06h6z46l0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=bfIT0T2A; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.94 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-1.01)[-1.013]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.38)[-0.379]; NEURAL_HAM_MEDIUM(-1.05)[-1.051]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[svn-src-head,svn-src-all] 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: Mon, 02 Nov 2020 22:40:49 -0000 On Tue, 3 Nov 2020 00:32:14 +0200 Konstantin Belousov wrote: > On Mon, Nov 02, 2020 at 11:22:15PM +0100, Emmanuel Vadot wrote: > > On Tue, 3 Nov 2020 00:10:39 +0200 > > Konstantin Belousov wrote: > > > > > On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote: > > > > I think that the first question we want to ask is : Do we want to > > > > support LOCALBASE being different than /usr/local > > > > 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. > > > > If they have some good argument, then we should proceed further. > > > > > > I would be delighted to be able to install _and use_ two independent > > > set of packages from the same base system install. Without recursing > > > to jails, X forwarding, etc. > > > > > > In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64 > > > machine. I am fine with me building both of them in my instance of > > > poudriere. > > > > > > But indeed I am not sure if this worth the effort of many people, for many > > > hours. If it puts too high burden on everybody, then it is not a good > > > feature. Otherwise, it is very convenient in some situations. > > > > I understand this situation but I think that the best way for you do > > do that is to use pkg install -r /path/to/my/i386/packages > > > > Since you will need to tweak you PATH variable to start applications > > installed in /usr/local-i386 anyway it's not too much to tweak that to > > the pkg path for your i386 repo. > > > > The "downside" of using this method is that you will have > > a /usr/local/ under the /path/to/my/i386/packages. > > The "upside" of using this method is that you would be able to use the > > same i386 packages on a native i386 install and they would install > > in /usr/local/ (so no tweaking here). > If I can already use them from non-/usr/local prefix, then it is great > news (for me). But I have a reason to doubt. If you pkg -r packages you can use a lot of them. > For instance, a lot of applications are configured at build time to look > for /usr/local. Like, gcc with /usr/local/lib/gcc/, and binutils, > which are actually one of the main use case for me. So I believe that > pkg install -r requires chroot/jail for the result to work. Yes there is still some cases like that, or packages having post-install script that don't handle -r. We've been working on that with bapt@ for a few months now and still do. The main motivation of rewriting everything in lua is to be able to do that but there is still a lot do to. Never the less we would appriciate some reports of people using packages installed with -r. -- Emmanuel Vadot