From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
To: "mgorny@gentoo.org" <mgorny@gentoo.org>,
"gentoo-portage-dev@lists.gentoo.org"
<gentoo-portage-dev@lists.gentoo.org>
Subject: Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
Date: Fri, 23 Mar 2018 00:52:31 +0000 [thread overview]
Message-ID: <1521766349.4790.337.camel@infinera.com> (raw)
In-Reply-To: <69cb373e-9260-9f06-058d-ed269509484b@gentoo.org>
On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote:
> On 03/15/2018 12:22 PM, Michał Górny wrote:
> > Hi,
> >
> > Here are three of four INSTALL_MASK updates I've sent long time ago
> > which were not really reviewed. The fourth patch added support
> > for repo-defined install-mask.conf and I'll do that separately.
> >
> > Those patches focus on smaller changes. What they change, in order:
> >
> > 1. Removes explicit file removal code for FEATURES=no*. Instead, those
> > values are converted into additional INSTALL_MASK entries
> > and handled directly via INSTALL_MASK processing.
> >
> > 2. Rework INSTALL_MASK to filter files while installing instead of
> > pre-stripping them. In other words, before: INSTALL_MASK removes
> > files from ${D} before merge. After: ${D} contains all the files,
> > Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that.
> >
> > 3. Adds support for exclusions in INSTALL_MASK. In other words, you
> > can do stuff like:
> >
> > INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US"
> >
> > I have been using this via user patches since the last submission.
> > Guessing by 'git log', this means almost 2 years now.
> >
> > --
> > Best regards,
> > Michał Górny
> >
> > Michał Górny (3):
> > portage.package.ebuild.config: Move FEATURES=no* handling there
> > portage.dbapi.vartree: Move INSTALL_MASK handling into merging
> > portage.dbapi.vartree: Support exclusions in INSTALL_MASK
> >
> > bin/misc-functions.sh | 30 ----------
> > pym/portage/dbapi/vartree.py | 104 ++++++++++++++++++++++-------------
> > pym/portage/package/ebuild/config.py | 11 ++++
> > 3 files changed, 77 insertions(+), 68 deletions(-)
> >
>
> As mentioned in #gentoo-portage today, the rationale for including the
> INSTALL_MASKed files in CONTENTS is to that we can detect collisions
> that would have occurred had people not been using INSTALL_MASK.
>
> Since people can use INSTALL_MASK to intentionally prevent collisions,
> in cases where COLLISION_IGNORE is not appropriate (this is common
> practice at my workplace), we'll need a new FEATURES setting to trigger
> the new behavior where INSTALL_MASKed files still trigger file collisions.
Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?
next prev parent reply other threads:[~2018-03-23 0:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 19:22 [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit Michał Górny
2018-03-15 19:22 ` [gentoo-portage-dev] [PATCH 1/3] portage.package.ebuild.config: Move FEATURES=no* handling there Michał Górny
2018-03-15 19:22 ` [gentoo-portage-dev] [PATCH 2/3] portage.dbapi.vartree: Move INSTALL_MASK handling into merging Michał Górny
2018-03-15 19:22 ` [gentoo-portage-dev] [PATCH 3/3] portage.dbapi.vartree: Support exclusions in INSTALL_MASK Michał Górny
2018-03-15 21:02 ` Alec Warner
2018-03-15 21:17 ` Michał Górny
2018-03-15 21:44 ` Joakim Tjernlund
2018-03-16 7:50 ` Michał Górny
2018-03-16 8:08 ` Joakim Tjernlund
2018-03-16 5:10 ` [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit Zac Medico
2018-03-16 8:31 ` Joakim Tjernlund
2018-03-16 10:08 ` Michał Górny
2018-03-16 17:07 ` Zac Medico
2018-03-16 21:13 ` Michał Górny
2018-03-16 21:25 ` Zac Medico
2018-03-18 9:03 ` Michał Górny
2018-03-18 18:22 ` Zac Medico
2018-03-19 6:27 ` Joakim Tjernlund
2018-03-16 8:11 ` Joakim Tjernlund
2018-03-16 8:13 ` Michał Górny
2018-03-18 9:57 ` Joakim Tjernlund
2018-03-19 22:59 ` Zac Medico
2018-03-23 0:52 ` Joakim Tjernlund [this message]
2018-03-23 1:09 ` Zac Medico
2018-03-23 8:33 ` Michał Górny
2018-03-23 9:05 ` Joakim Tjernlund
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=1521766349.4790.337.camel@infinera.com \
--to=joakim.tjernlund@infinera.com \
--cc=gentoo-portage-dev@lists.gentoo.org \
--cc=mgorny@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