From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 10227158013 for ; Mon, 27 Sep 2021 10:56:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ED32DE0908; Mon, 27 Sep 2021 10:56:14 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D2517E0908 for ; Mon, 27 Sep 2021 10:56:14 +0000 (UTC) Message-ID: Subject: Re: [gentoo-portage-dev] [PATCH v3] Copy files/* into the work tree instead of symlinking it From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-portage-dev@lists.gentoo.org Date: Mon, 27 Sep 2021 12:56:10 +0200 In-Reply-To: References: <20210926102004.654443-1-mgorny@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: bdd78a58-e47a-4038-a26d-1d677a15142a X-Archives-Hash: 99b2295b8e4dd0df575f98c0359a43ca On Mon, 2021-09-27 at 12:49 +0200, Ulrich Mueller wrote: > > > > > > On Sun, 26 Sep 2021, Michał Górny wrote: > > > Symlinking FILESDIR into the work tree has the unintended > > consequence > > of preserving all original file metadata, including system-specific > > ACLs > > and so on. When these files are installed, this could lead to > > unintentionally copying this metadata to the system and/or binary > > packages. > > > Let's copy all files instead and drop metadata in the process. > > Since > > FILESDIR is expected to be small by design, this shouldn't cause any > > major trouble. It is also easier and less likely to cause > > regressions > > than making sure stuff is not preserved when installing. > > > Unfortunately, a similar problem applies to DISTDIR. However, > > installing files from DISTDIR is rarer than from FILESDIR, so I > > guess > > we'll cross that bridge when we get to it. > > Sorry for the late reply, but this looks like the wrong solution to > me. > > Looking at the installation helpers (doins, doexe, etc.), they don't > preserve the normal permission bits, but reset them to a defined > state. > So why would they preserve xattrs? > > I don't see anything in PMS that would mandate that behaviour (on the > contrary, in section 13.3.1 there is "Other file attributes may be > discarded"). How do the other package managers handle this? Yes, I agree this is the wrong long-term solution but it's a fix that works today and shouldn't cause regressions. I'd like to revisit how files are installed long-term but this requires more time, and most importantly making sure we won't accidentally break stuff. I'd like to establish whether we have any ebuilds relying e.g. on caps or ACLs being preserved from src_install(), and get alternative solutions to that first (fcaps.eclass-alike?). Apparently PaX will also require special fixes but I'm not sure if it's worth fixing at this point. -- Best regards, Michał Górny