public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] [PATCH v3] Copy files/* into the work tree instead of symlinking it
Date: Mon, 27 Sep 2021 12:56:10 +0200	[thread overview]
Message-ID: <c4984bd5e924889a1c9073c17a32e8980b6919c0.camel@gentoo.org> (raw)
In-Reply-To: <u7df2jntj@gentoo.org>

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




      reply	other threads:[~2021-09-27 10:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-26 10:20 [gentoo-portage-dev] [PATCH v3] Copy files/* into the work tree instead of symlinking it Michał Górny
2021-09-27 10:49 ` Ulrich Mueller
2021-09-27 10:56   ` Michał Górny [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4984bd5e924889a1c9073c17a32e8980b6919c0.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox