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? > > 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. -- Best regards, Michał Górny