Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On Fri, 2018-03-23 at 09:33 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> W dniu pią, 23.03.2018 o godzinie 00∶52 +, użytkownik Joakim
> Tjernlund napisał:
> > On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote:
> > > 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(-)
> > > >
> > >
> > > As mentioned in #gentoo-portage today, the rationale for including the
> > > INSTALL_MASKed files in CONTENTS is to that we can detect collisions
> > > that would have occurred had people not been using INSTALL_MASK.
> > >
> > > Since people can use INSTALL_MASK to intentionally prevent collisions,
> > > in cases where COLLISION_IGNORE is not appropriate (this is common
> > > practice at my workplace), we'll need a new FEATURES setting to trigger
> > > the new behavior where INSTALL_MASKed files still trigger file collisions.
> >
> > Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?
>
> It's in sys-apps/portage-mgorny. Whatever's going to land in sys-
> apps/portage, it's probably going to be half-broken to satisfy
> somebody's colleague's corner case of misusing INSTALL_MASK.
I looked and saw the INSTALL_MASK part but no mention of PKG_INSTALL_MASK(which
is what I need)
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
W dniu pią, 23.03.2018 o godzinie 00∶52 +, użytkownik Joakim
Tjernlund napisał:
> On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote:
> > 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(-)
> > >
> >
> > As mentioned in #gentoo-portage today, the rationale for including the
> > INSTALL_MASKed files in CONTENTS is to that we can detect collisions
> > that would have occurred had people not been using INSTALL_MASK.
> >
> > Since people can use INSTALL_MASK to intentionally prevent collisions,
> > in cases where COLLISION_IGNORE is not appropriate (this is common
> > practice at my workplace), we'll need a new FEATURES setting to trigger
> > the new behavior where INSTALL_MASKed files still trigger file collisions.
>
> Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?
It's in sys-apps/portage-mgorny. Whatever's going to land in sys-
apps/portage, it's probably going to be half-broken to satisfy
somebody's colleague's corner case of misusing INSTALL_MASK.
--
Best regards,
Michał Górny
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On 03/22/2018 05:52 PM, Joakim Tjernlund wrote:
> On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote:
>> 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(-)
>>>
>>
>> As mentioned in #gentoo-portage today, the rationale for including the
>> INSTALL_MASKed files in CONTENTS is to that we can detect collisions
>> that would have occurred had people not been using INSTALL_MASK.
>>
>> Since people can use INSTALL_MASK to intentionally prevent collisions,
>> in cases where COLLISION_IGNORE is not appropriate (this is common
>> practice at my workplace), we'll need a new FEATURES setting to trigger
>> the new behavior where INSTALL_MASKed files still trigger file collisions.
>
> Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?
Yes, I'll clean up the patches an resubmit them. Bug filed:
https://bugs.gentoo.org/651214
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote:
> 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(-)
> >
>
> As mentioned in #gentoo-portage today, the rationale for including the
> INSTALL_MASKed files in CONTENTS is to that we can detect collisions
> that would have occurred had people not been using INSTALL_MASK.
>
> Since people can use INSTALL_MASK to intentionally prevent collisions,
> in cases where COLLISION_IGNORE is not appropriate (this is common
> practice at my workplace), we'll need a new FEATURES setting to trigger
> the new behavior where INSTALL_MASKed files still trigger file collisions.
Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
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(-)
>
As mentioned in #gentoo-portage today, the rationale for including the
INSTALL_MASKed files in CONTENTS is to that we can detect collisions
that would have occurred had people not been using INSTALL_MASK.
Since people can use INSTALL_MASK to intentionally prevent collisions,
in cases where COLLISION_IGNORE is not appropriate (this is common
practice at my workplace), we'll need a new FEATURES setting to trigger
the new behavior where INSTALL_MASKed files still trigger file collisions.
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On Sun, 2018-03-18 at 10:03 +0100, Michał Górny wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > W dniu czw, 15.03.2018 o godzinie 22∶10 -0700, użytkownik Zac Medico > napisał: > > A binary package should > > use the value of INSTALL_MASK that existed at build time. > > > > Wait a minute! This doesn't make any sense. The whole point of having > separate PKG_INSTALL_MASK and INSTALL_MASK is to be able to strip stuff > from more complete binary packages, not to force original restrictions > forever. These discussions also mentions PKG_INSTALL_MASK while the actual patches only mention INSTALL_MASK. I am getting somewhat confused, does the patches support PKG_INSTALL_MASK too or do you only intend to support this new exclusion syntax in INSTALL_MASK? Jocke
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On 03/18/2018 02:03 AM, Michał Górny wrote: > W dniu czw, 15.03.2018 o godzinie 22∶10 -0700, użytkownik Zac Medico > napisał: >> A binary package should >> use the value of INSTALL_MASK that existed at build time. >> > > Wait a minute! This doesn't make any sense. The whole point of having > separate PKG_INSTALL_MASK and INSTALL_MASK is to be able to strip stuff > from more complete binary packages, not to force original restrictions > forever. Okay, we should apply latest INSTALL_MASK settings when installing a binary package? That seems reasonable. I want to respect settings embedded in the binary package whenever it could be useful, since my intention if for binhost clients to be able to treat the binhost as a single source of truth, so that binary packages can be installed without dependency on source ebuild repositories/profiles, as discussed here: https://bugs.gentoo.org/644990 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On Fri, 2018-03-16 at 09:13 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> W dniu pią, 16.03.2018 o godzinie 08∶11 +, użytkownik Joakim
> Tjernlund napisał:
> > On Thu, 2018-03-15 at 20:22 +0100, Michał Górny wrote:
> > > CAUTION: This email originated from outside of the organization. Do not
> > > click links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > >
> > > 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.
> >
> > Will this also remove corresponding split debug files?
> > There would be little/no point in keeping debug syms if the binary has been
> > MASKed
> >
>
> Nope. Add both paths to INSTALL_MASK. Expecting it to do implicit magic
> is a very bad idea.
Maybe but it also makes senses to get rid of them. To me it is only a matter
of applying PKG_INSTALL_MASK before applying strip debug, does that make sense ?
Jocke
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
W dniu czw, 15.03.2018 o godzinie 22∶10 -0700, użytkownik Zac Medico napisał: > A binary package should > use the value of INSTALL_MASK that existed at build time. > Wait a minute! This doesn't make any sense. The whole point of having separate PKG_INSTALL_MASK and INSTALL_MASK is to be able to strip stuff from more complete binary packages, not to force original restrictions forever. -- Best regards, Michał Górny
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
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
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
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
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
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?
Should the merge code do that explicitly while handling INSTALL_MASK, or
should some of the config classes do that?
--
Best regards,
Michał Górny
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On Thu, 2018-03-15 at 22:10 -0700, Zac Medico wrote:
> 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.
Why does unmerge code need to know PKG_INSTALL_MASK? The files are not
installed so nothing to filter ?
similarly for merge of binary pkgs I guess, PKG_INSTALL_MASKed files are not
in the binary packed so no need to something special in this case ?
>
> 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).
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
W dniu pią, 16.03.2018 o godzinie 08∶11 +, użytkownik Joakim
Tjernlund napisał:
> On Thu, 2018-03-15 at 20:22 +0100, Michał Górny wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
> > the content is safe.
> >
> >
> > 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.
>
> Will this also remove corresponding split debug files?
> There would be little/no point in keeping debug syms if the binary has been
> MASKed
>
Nope. Add both paths to INSTALL_MASK. Expecting it to do implicit magic
is a very bad idea.
--
Best regards,
Michał Górny
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
On Thu, 2018-03-15 at 20:22 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> 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.
Will this also remove corresponding split debug files?
There would be little/no point in keeping debug syms if the binary has been
MASKed
Jocke
Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit
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).
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
