On 03/16/2018 02:13 PM, Michał Górny wrote:
> W dniu pią, 16.03.2018 o godzinie 10∶07 -0700, użytkownik Zac Medico
> napisał:
>> 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.
>
> But do I need to change anything for PKG_INSTALL_MASK? My original patch
> did not touch that, so it can just continue happening as it is now.
>
>> INSTALL_MASK should be handled in the dblink treewalk method like it is now.
>
> But we also need to read it for unmerge, correct?
Oh right. We should load it in the dblink _match_contents or getcontents
method, since we need it for operation of the _match_contents method
which is called by isowner.
>>> 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
signature.asc
Description: OpenPGP digital signature
