[gentoo-dev] package.use.mask / package.use.stable.mask priority

[gentoo-dev] package.use.mask / package.use.stable.mask priority

[Bernard Cafarelli]

Hi folks,

gnustep-base/gnustep-make has a USE flag (libobjc2) masked globally in
base/package.use.mask, and unmasked on specific arches in
arch/{amd64,x86}/package.use.mask

To get a stabilization (#579232) bug finally moving on, I wanted to
leave this flag out, adding a corresponding line in
base/package.use.stable.mask

But repoman replied with a batch of dependency.bad errors...
Does package.use.mask (stable and ~arch) have a higher priority on
package.use.stable.mask (stable only)? Bug or intended behavior?

In the meantime, I will probably work around this by duplicating the
package.use.stable.mask entry in arches files

-- 
Bernard Cafarelli (Voyageur)
Gentoo developer

Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority

[Zac Medico]

On 01/10/2017 01:56 PM, Bernard Cafarelli wrote:
> Hi folks,
> 
> gnustep-base/gnustep-make has a USE flag (libobjc2) masked globally in
> base/package.use.mask, and unmasked on specific arches in
> arch/{amd64,x86}/package.use.mask
> 
> To get a stabilization (#579232) bug finally moving on, I wanted to
> leave this flag out, adding a corresponding line in
> base/package.use.stable.mask
> 
> But repoman replied with a batch of dependency.bad errors...
> Does package.use.mask (stable and ~arch) have a higher priority on
> package.use.stable.mask (stable only)? Bug or intended behavior?
> 
> In the meantime, I will probably work around this by duplicating the
> package.use.stable.mask entry in arches files
> 

If I understand you correctly, then it's the intended behavior. If the
flag is masked in both package.use.mask and package.use.stable.mask,
then the package.use.stable.mask setting is irrelevant because both
package.use.mask and package.use.stable.mask are considered when
calculating use.mask settings for any given package.
-- 
Thanks,
Zac

Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority

[Bernard Cafarelli]

Le Tue, 10 Jan 2017 14:09:07 -0800
Zac Medico <zmedico@gentoo.org> a écrit:

> On 01/10/2017 01:56 PM, Bernard Cafarelli wrote:
> > Hi folks,
> > 
> > gnustep-base/gnustep-make has a USE flag (libobjc2) masked globally in
> > base/package.use.mask, and unmasked on specific arches in
> > arch/{amd64,x86}/package.use.mask
> > 
> > To get a stabilization (#579232) bug finally moving on, I wanted to
> > leave this flag out, adding a corresponding line in
> > base/package.use.stable.mask
> > 
> > But repoman replied with a batch of dependency.bad errors...
> > Does package.use.mask (stable and ~arch) have a higher priority on
> > package.use.stable.mask (stable only)? Bug or intended behavior?
> > 
> > In the meantime, I will probably work around this by duplicating the
> > package.use.stable.mask entry in arches files
> >   
> 
> If I understand you correctly, then it's the intended behavior. If the
> flag is masked in both package.use.mask and package.use.stable.mask,
> then the package.use.stable.mask setting is irrelevant because both
> package.use.mask and package.use.stable.mask are considered when
> calculating use.mask settings for any given package.

Thanks for the confirmation! I fixed it at arch level:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef57bcf1f6505b79d0cf696ba8f196df1d6f9c9c


-- 
Bernard Cafarelli (Voyageur)
Gentoo developer

Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

>>>>> On Tue, 10 Jan 2017, Zac Medico wrote:

> On 01/10/2017 01:56 PM, Bernard Cafarelli wrote:
>> gnustep-base/gnustep-make has a USE flag (libobjc2) masked globally in
>> base/package.use.mask, and unmasked on specific arches in
>> arch/{amd64,x86}/package.use.mask
>> 
>> To get a stabilization (#579232) bug finally moving on, I wanted to
>> leave this flag out, adding a corresponding line in
>> base/package.use.stable.mask

So do I understand this correctly, there is:
flag in base/package.use.mask,
-flag in arch/{amd64,x86}/package.use.mask, and
flag in base/package.use.stable.mask?

>> But repoman replied with a batch of dependency.bad errors...
>> Does package.use.mask (stable and ~arch) have a higher priority on
>> package.use.stable.mask (stable only)? Bug or intended behavior?

> If I understand you correctly, then it's the intended behavior. If the
> flag is masked in both package.use.mask and package.use.stable.mask,
> then the package.use.stable.mask setting is irrelevant because both
> package.use.mask and package.use.stable.mask are considered when
> calculating use.mask settings for any given package.

I believe this is not correct. package.use.stable.mask should take
precedence within the same profile:
https://projects.gentoo.org/pms/6/pms.html#x1-58002r1

The problem here is rather that the base profile is processed as a
whole before the arch specific profile, so you end up with -flag from
the arch profile.

Putting flag in arch/{amd64,x86}/package.use.stable.mask should solve
it.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority

[Zac Medico]

On 01/10/2017 11:30 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 10 Jan 2017, Zac Medico wrote:
> 
>> On 01/10/2017 01:56 PM, Bernard Cafarelli wrote:
>>> But repoman replied with a batch of dependency.bad errors...
>>> Does package.use.mask (stable and ~arch) have a higher priority on
>>> package.use.stable.mask (stable only)? Bug or intended behavior?
> 
>> If I understand you correctly, then it's the intended behavior. If the
>> flag is masked in both package.use.mask and package.use.stable.mask,
>> then the package.use.stable.mask setting is irrelevant because both
>> package.use.mask and package.use.stable.mask are considered when
>> calculating use.mask settings for any given package.
> 
> I believe this is not correct. package.use.stable.mask should take
> precedence within the same profile:
> https://projects.gentoo.org/pms/6/pms.html#x1-58002r1

Oh, right. I misunderstood because I misread the original email. I
should have looked at the profile state to avoid a misunderstanding:

profiles/arch/amd64/package.use.mask:gnustep-base/gnustep-make -libobjc2
profiles/arch/x86/package.use.mask:gnustep-base/gnustep-make -libobjc2
profiles/base/package.use.mask:>=gnustep-base/gnustep-make-2.6.2 libobjc2

I've checked the portage code and package.use.stable.mask does in fact
take precedence within the same profile, because the UseManager
getUseForce method uses an algorithm equivalent to the one specified in pms.
-- 
Thanks,
Zac

Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority

[Bernard Cafarelli]

Le 11/01/2017 8:30, Ulrich Mueller a écrit :
>>>>>> On Tue, 10 Jan 2017, Zac Medico wrote:
> 
>> On 01/10/2017 01:56 PM, Bernard Cafarelli wrote:
>>> gnustep-base/gnustep-make has a USE flag (libobjc2) masked globally 
>>> in
>>> base/package.use.mask, and unmasked on specific arches in
>>> arch/{amd64,x86}/package.use.mask
>>> 
>>> To get a stabilization (#579232) bug finally moving on, I wanted to
>>> leave this flag out, adding a corresponding line in
>>> base/package.use.stable.mask
> 
> So do I understand this correctly, there is:
> flag in base/package.use.mask,
> -flag in arch/{amd64,x86}/package.use.mask, and
> flag in base/package.use.stable.mask?

Exactly :)

>>> But repoman replied with a batch of dependency.bad errors...
>>> Does package.use.mask (stable and ~arch) have a higher priority on
>>> package.use.stable.mask (stable only)? Bug or intended behavior?
> 
>> If I understand you correctly, then it's the intended behavior. If the
>> flag is masked in both package.use.mask and package.use.stable.mask,
>> then the package.use.stable.mask setting is irrelevant because both
>> package.use.mask and package.use.stable.mask are considered when
>> calculating use.mask settings for any given package.
> 
> I believe this is not correct. package.use.stable.mask should take
> precedence within the same profile:
> https://projects.gentoo.org/pms/6/pms.html#x1-58002r1
> 
> The problem here is rather that the base profile is processed as a
> whole before the arch specific profile, so you end up with -flag from
> the arch profile.
> 
> Putting flag in arch/{amd64,x86}/package.use.stable.mask should solve
> it.
Indeed, I tested (and committed) this yesterday and repoman was happy 
again

-- 
Bernard Cafarelli (Voyageur)
Gentoo developer

USE=doc gnustep-make broken (was: Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority)

[David Haller]

Hello,

On Wed, 11 Jan 2017, Bernard Cafarelli wrote:
>Le 11/01/2017 8:30, Ulrich Mueller a écrit :
[..]
>> Putting flag in arch/{amd64,x86}/package.use.stable.mask should solve
>> it.
>Indeed, I tested (and committed) this yesterday and repoman was happy again

gnustep-base/gnustep-make-2.6.8.ebuild is broken when built with USE=doc,
as it tries to install into the system, not the image. Easy fix:

==== 
diff -U7 -r a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild
--- a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild	2017-01-14 19:55:10.658259392 +0100
+++ b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild	2017-01-14 19:55:17.158259179 +0100
@@ -97,15 +97,15 @@
 src_compile() {
 	emake
 	# Prepare doc here (needed when no gnustep-make is already installed)
 	if use doc ; then
 		# If a gnustep-1 environment is set
 		unset GNUSTEP_MAKEFILES
 		pushd Documentation &> /dev/null
-		emake -j1 all install
+		emake -j1 all install DESTDIR="${D}"
 		popd &> /dev/null
 	fi
 }
 
 src_install() {
 	# Get GNUSTEP_* variables
 	. ./GNUstep.conf
====

HTH,
-dnh

-- 
What once was muesli is now of a colour and (from the looks) consistency
unheard of in dairy produce.  At a second guess, it might be running for
political office by the time flattie's back.
                                       -- The Bastard Flatmate From Hell

Re: USE=doc gnustep-make broken (was: Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority)

[Bernard Cafarelli]

Le Sat, 14 Jan 2017 20:03:02 +0100
David Haller <gentoo@dhaller.de> a écrit:
> gnustep-base/gnustep-make-2.6.8.ebuild is broken when built with USE=doc,
> as it tries to install into the system, not the image. Easy fix:
> 
> ==== 
> diff -U7 -r a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild
> --- a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild	2017-01-14 19:55:10.658259392 +0100
> +++ b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild	2017-01-14 19:55:17.158259179 +0100
> @@ -97,15 +97,15 @@
>  src_compile() {
>  	emake
>  	# Prepare doc here (needed when no gnustep-make is already installed)
>  	if use doc ; then
>  		# If a gnustep-1 environment is set
>  		unset GNUSTEP_MAKEFILES
>  		pushd Documentation &> /dev/null
> -		emake -j1 all install
> +		emake -j1 all install DESTDIR="${D}"
>  		popd &> /dev/null
>  	fi
>  }
>  
>  src_install() {
>  	# Get GNUSTEP_* variables
>  	. ./GNUstep.conf
> ====

This was also reported in an update to bug #585796, in fact the
workaround for USE=doc was not needed anymore for some versions (and
ended up running install parts in src_compile).

Fixed in current 2.6.8 ebuild (as it did not install anyway with
USE=doc):
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b60b455a60115d9226cb66b4b383ff057c8a023

-- 
Bernard Cafarelli (Voyageur)
Gentoo developer