Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Zac Medico <zmedico@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3485 bytes --]

On 03/16/2018 03:08 AM, Michał Górny wrote:
> W dniu czw, 15.03.2018 o godzinie 22∶10 -0700, użytkownik Zac Medico
> napisał:
>> 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(-)
>>
>> I like this patch set but here are some important things that I want it
>> to do differently:
>>
>> 1) For the unmerge code, it needs to read the appropriate
>> /var/db/pkg/*/*/{PKG,}INSTALL_MASK file in order to account for the
>> {PKG,}INSTALL_MASK settings that existed when the package was built
>> (PKG_INSTALL_MASK) and merged (INSTALL_MASK). A binary package should
>> use the value of INSTALL_MASK that existed at build time.
> 
>> 2) In order to support bashrc {PKG,}INSTALL_MASK settings, we need to
>> write the values from the environment to
>> ${PORTAGE_BUILDDIR}/build-info/{PKG,}INSTALL_MASK and read them from
>> there (we do this for many other variables including QA_PREBUILT).
> 
> I presume bin/phase-functions.sh __dyn_install is where I'm supposed to
> write them. Could you suggest where is the best place to read them back?

We can read them back just when they are needed.

PKG_INSTALL_MASK should be handled in the EbuildPhase class when
self.phase is "package". In order to preserve behavior, EbuildPhase will
have to create a temporary copy of ${D} and apply PKG_INSTALL_MASK to
it, for __dyn_package to use.

INSTALL_MASK should be handled in the dblink treewalk method like it is now.


> Should the merge code do that explicitly while handling INSTALL_MASK, or
> should some of the config classes do that?

The config class only needs to be involved if we want to expose some API
related to {PKG,}INSTALL_MASK there, but the config class is bloated
enough as it is so it's better to expose a helper class like the
ConfigProtect class.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]