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