| 1 |
On 03/16/2018 02:13 PM, Michał Górny wrote: |
| 2 |
> W dniu pią, 16.03.2018 o godzinie 10∶07 -0700, użytkownik Zac Medico |
| 3 |
> napisał: |
| 4 |
>> On 03/16/2018 03:08 AM, Michał Górny wrote: |
| 5 |
>>> W dniu czw, 15.03.2018 o godzinie 22∶10 -0700, użytkownik Zac Medico |
| 6 |
>>> napisał: |
| 7 |
>>>> On 03/15/2018 12:22 PM, Michał Górny wrote: |
| 8 |
>>>>> Hi, |
| 9 |
>>>>> |
| 10 |
>>>>> Here are three of four INSTALL_MASK updates I've sent long time ago |
| 11 |
>>>>> which were not really reviewed. The fourth patch added support |
| 12 |
>>>>> for repo-defined install-mask.conf and I'll do that separately. |
| 13 |
>>>>> |
| 14 |
>>>>> Those patches focus on smaller changes. What they change, in order: |
| 15 |
>>>>> |
| 16 |
>>>>> 1. Removes explicit file removal code for FEATURES=no*. Instead, those |
| 17 |
>>>>> values are converted into additional INSTALL_MASK entries |
| 18 |
>>>>> and handled directly via INSTALL_MASK processing. |
| 19 |
>>>>> |
| 20 |
>>>>> 2. Rework INSTALL_MASK to filter files while installing instead of |
| 21 |
>>>>> pre-stripping them. In other words, before: INSTALL_MASK removes |
| 22 |
>>>>> files from ${D} before merge. After: ${D} contains all the files, |
| 23 |
>>>>> Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that. |
| 24 |
>>>>> |
| 25 |
>>>>> 3. Adds support for exclusions in INSTALL_MASK. In other words, you |
| 26 |
>>>>> can do stuff like: |
| 27 |
>>>>> |
| 28 |
>>>>> INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US" |
| 29 |
>>>>> |
| 30 |
>>>>> I have been using this via user patches since the last submission. |
| 31 |
>>>>> Guessing by 'git log', this means almost 2 years now. |
| 32 |
>>>>> |
| 33 |
>>>>> -- |
| 34 |
>>>>> Best regards, |
| 35 |
>>>>> Michał Górny |
| 36 |
>>>>> |
| 37 |
>>>>> Michał Górny (3): |
| 38 |
>>>>> portage.package.ebuild.config: Move FEATURES=no* handling there |
| 39 |
>>>>> portage.dbapi.vartree: Move INSTALL_MASK handling into merging |
| 40 |
>>>>> portage.dbapi.vartree: Support exclusions in INSTALL_MASK |
| 41 |
>>>>> |
| 42 |
>>>>> bin/misc-functions.sh | 30 ---------- |
| 43 |
>>>>> pym/portage/dbapi/vartree.py | 104 ++++++++++++++++++++++------------- |
| 44 |
>>>>> pym/portage/package/ebuild/config.py | 11 ++++ |
| 45 |
>>>>> 3 files changed, 77 insertions(+), 68 deletions(-) |
| 46 |
>>>> |
| 47 |
>>>> I like this patch set but here are some important things that I want it |
| 48 |
>>>> to do differently: |
| 49 |
>>>> |
| 50 |
>>>> 1) For the unmerge code, it needs to read the appropriate |
| 51 |
>>>> /var/db/pkg/*/*/{PKG,}INSTALL_MASK file in order to account for the |
| 52 |
>>>> {PKG,}INSTALL_MASK settings that existed when the package was built |
| 53 |
>>>> (PKG_INSTALL_MASK) and merged (INSTALL_MASK). A binary package should |
| 54 |
>>>> use the value of INSTALL_MASK that existed at build time. |
| 55 |
>>>> 2) In order to support bashrc {PKG,}INSTALL_MASK settings, we need to |
| 56 |
>>>> write the values from the environment to |
| 57 |
>>>> ${PORTAGE_BUILDDIR}/build-info/{PKG,}INSTALL_MASK and read them from |
| 58 |
>>>> there (we do this for many other variables including QA_PREBUILT). |
| 59 |
>>> |
| 60 |
>>> I presume bin/phase-functions.sh __dyn_install is where I'm supposed to |
| 61 |
>>> write them. Could you suggest where is the best place to read them back? |
| 62 |
>> |
| 63 |
>> We can read them back just when they are needed. |
| 64 |
>> |
| 65 |
>> PKG_INSTALL_MASK should be handled in the EbuildPhase class when |
| 66 |
>> self.phase is "package". In order to preserve behavior, EbuildPhase will |
| 67 |
>> have to create a temporary copy of ${D} and apply PKG_INSTALL_MASK to |
| 68 |
>> it, for __dyn_package to use. |
| 69 |
> |
| 70 |
> But do I need to change anything for PKG_INSTALL_MASK? My original patch |
| 71 |
> did not touch that, so it can just continue happening as it is now. |
| 72 |
> |
| 73 |
>> INSTALL_MASK should be handled in the dblink treewalk method like it is now. |
| 74 |
> |
| 75 |
> But we also need to read it for unmerge, correct? |
| 76 |
|
| 77 |
Oh right. We should load it in the dblink _match_contents or getcontents |
| 78 |
method, since we need it for operation of the _match_contents method |
| 79 |
which is called by isowner. |
| 80 |
|
| 81 |
>>> Should the merge code do that explicitly while handling INSTALL_MASK, or |
| 82 |
>>> should some of the config classes do that? |
| 83 |
>> |
| 84 |
>> The config class only needs to be involved if we want to expose some API |
| 85 |
>> related to {PKG,}INSTALL_MASK there, but the config class is bloated |
| 86 |
>> enough as it is so it's better to expose a helper class like the |
| 87 |
>> ConfigProtect class. |
| 88 |
> |
| 89 |
|
| 90 |
|
| 91 |
-- |
| 92 |
Thanks, |
| 93 |
Zac |
Archives