[gentoo-dev] Extending EAPI="4"

[gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 177 bytes --]

I would like to suggest that EAPI="4" be reopened for ability of using dots in
USE flag names, which was suggested in bug #311795.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 3056 bytes --]

I would like to request that 2 additional features are added to EAPI="4".
These features will be needed for further development of python.eclass.

1. Support for "." characters in names of USE flags
2. Support for use.unsatisfiable and package.use.unsatisfiable files in profiles
These files would have the same syntax as use.mask and package.use.mask, respectively.
These files would indicate that it's allowed for dependencies conditional on USE flags specified
in these files to be unsatisfiable. It would allow for stable packages to have optional
dependencies on packages, which cannot be stabilized yet. This feature would be a better
replacement for possibility of masking of USE flags only on stable systems, which was considered
in the past.

  Example dependencies:
    DEPEND="python_abis_2.4? ( dev-lang/python:2.4 )
            python_abis_2.5? ( dev-lang/python:2.5 )
            python_abis_2.6? ( dev-lang/python:2.6 )
            python_abis_2.7? ( dev-lang/python:2.7 )
            python_abis_3.1? ( dev-lang/python:3.1 )
            python_abis_3.2? ( dev-lang/python:3.2 )"
    RDEPEND="${DEPEND}"

python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags would be specified in use.unsatisfiable
file until relevant versions of Python are stabilized on all architectures. Without this feature,
some USE flags would have to be masked, so unstable users couldn't easily test many packages with
new versions of Python.

Another example: dev-vcs/subversion[kde] depends on >=kde-base/kdelibs-4. dev-vcs/subversion is
stable on arm and ppc64, but kde-base/kdelibs is unstable on these architectures, which causes
that currently "kde" USE flag of dev-vcs/subversion is masked in arm and ppc64 profiles, which
causes that users of ~arm or ~ppc64 would have to manually unmask this USE flag in
/etc/portage/profile/package.use.mask to be able to install dev-vcs/subversion with "kde" USE flag
enabled. With this feature, users wouldn't need to edit /etc/portage/profile/package.use.mask.

use.unsatisfiable and package.use.unsatisfiable files would cause that `repoman` would treat
given USE flags in the same way as masked USE flags. These files wouldn't affect behavior of
`emerge`:
 - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
   and if optional dependencies controlled by this USE flag are already installed or satisfiable,
   then `emerge` will allow to install given package.
 - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
   and if optional dependencies controlled by this USE flag cannot be satisfied (with current
   settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then `emerge` will print
   informative error message telling e.g. about a dependency masked by ~${ARCH} keyword.


I have a patch, which adds support for these features in Portage, so inclusion of these features
in EAPI="4" wouldn't delay EAPI="4".

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Ciaran McCreesh]

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

On Mon, 25 Oct 2010 15:24:23 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> 1. Support for "." characters in names of USE flags

If you do this, you'll have to either convert everything using Python
ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users
get confused if they have to set both python_abis_3_2 (for EAPI < 4
packages) and python_abis_3.2 (for EAPI 4 packages)? And won't
developers have a hard time getting [use] deps right for them?

> 2. Support for use.unsatisfiable and package.use.unsatisfiable files
> in profiles

As far as I can see, this one's a repoman thing, and has little to no
impact on PMS since it doesn't require behaviour changes from the
package mangler itself.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 816 bytes --]

2010-10-25 15:42:00 Ciaran McCreesh napisał(a):
> On Mon, 25 Oct 2010 15:24:23 +0200
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > 1. Support for "." characters in names of USE flags
> 
> If you do this, you'll have to either convert everything using Python
> ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users
> get confused if they have to set both python_abis_3_2 (for EAPI < 4
> packages) and python_abis_3.2 (for EAPI 4 packages)?

There won't be any such USE flags for EAPI <4. I'm planning to use e.g. REQUIRED_USE, which isn't
available in EAPI <4.

> And won't developers have a hard time getting [use] deps right for them?

Appropriate dependencies will be automatically generated by python.eclass.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Ulrich Mueller]

>>>>> On Mon, 25 Oct 2010, Arfrever Frehtes Taifersar Arahesis wrote:

> 1. Support for "." characters in names of USE flags

Are you aware that this would break existing programs that do regexp
matching on USE flags? The current implementation of the useq()
function in portage is probably the most prominent example.

Ulrich

Re: [gentoo-dev] Extending EAPI="4"

[Ciaran McCreesh]

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

On Mon, 25 Oct 2010 15:56:18 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> 2010-10-25 15:42:00 Ciaran McCreesh napisał(a):
> > On Mon, 25 Oct 2010 15:24:23 +0200
> > Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > > 1. Support for "." characters in names of USE flags
> > 
> > If you do this, you'll have to either convert everything using
> > Python ABIs to EAPI 4 immediately, or have two sets of flag names.
> > Won't users get confused if they have to set both python_abis_3_2
> > (for EAPI < 4 packages) and python_abis_3.2 (for EAPI 4 packages)?
> 
> There won't be any such USE flags for EAPI <4.

Ok, that answers that objection. In that case I'd not be opposed to .
being allowed *provided*:

- Portage explicitly enforces it not being allowed anywhere else,
  including in profiles that aren't marked as eapi 4

- The . isn't legal as the first character in a flag name. (Paludis has
  been using [.foo=bar] and the like in user eapi contexts to allow
  fancy queries on metadata. It would be a shame to have to change
  that syntax just for some hypothetical possible use of . in use flag
  names that looks really really weird anyway.)

> I'm planning to use e.g. REQUIRED_USE, which isn't available in EAPI <4.

Or in EAPI 4 for that matter, going by the current state of GLEPs and
PMS...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Ciaran McCreesh]

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

On Mon, 25 Oct 2010 15:56:50 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Mon, 25 Oct 2010, Arfrever Frehtes Taifersar Arahesis wrote:
> > 1. Support for "." characters in names of USE flags
> 
> Are you aware that this would break existing programs that do regexp
> matching on USE flags? The current implementation of the useq()
> function in portage is probably the most prominent example.

That's already a can of worms, since @ is allowed in use flag names.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 447 bytes --]

2010-10-25 15:56:50 Ulrich Mueller napisał(a):
> >>>>> On Mon, 25 Oct 2010, Arfrever Frehtes Taifersar Arahesis wrote:
> 
> > 1. Support for "." characters in names of USE flags
> 
> Are you aware that this would break existing programs that do regexp
> matching on USE flags?

I suggest this feature in a new EAPI to avoid this problem.
(No program should parse anything from future EAPIs.)

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Fabio Erculiani]

Implementing a feature to just satisfy your tiny, corner-case (how
many people would take benefit out of it?) use case is just against
any software engineering best practice, and it's a good path towards
bloat and complexity. I think people can understand "python_abis_2_5"
well enough, besides being happy that their app will KEEP working.


-- 
Fabio Erculiani

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 555 bytes --]

2010-10-25 16:43:43 Fabio Erculiani napisał(a):
> Implementing a feature to just satisfy your tiny, corner-case (how
> many people would take benefit out of it?) use case is just against
> any software engineering best practice, and it's a good path towards
> bloat and complexity. I think people can understand "python_abis_2_5"
> well enough, besides being happy that their app will KEEP working.

"2_5" is very ugly and unacceptable. python.eclass already uses "2.5" (e.g. in RESTRICT_PYTHON_ABIS).

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1495 bytes --]

2010-10-25 16:03:01 Ciaran McCreesh napisał(a):
> On Mon, 25 Oct 2010 15:56:18 +0200
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > 2010-10-25 15:42:00 Ciaran McCreesh napisał(a):
> > > On Mon, 25 Oct 2010 15:24:23 +0200
> > > Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > > > 1. Support for "." characters in names of USE flags
> > > 
> > > If you do this, you'll have to either convert everything using
> > > Python ABIs to EAPI 4 immediately, or have two sets of flag names.
> > > Won't users get confused if they have to set both python_abis_3_2
> > > (for EAPI < 4 packages) and python_abis_3.2 (for EAPI 4 packages)?
> > 
> > There won't be any such USE flags for EAPI <4.
> 
> Ok, that answers that objection. In that case I'd not be opposed to .
> being allowed *provided*:
> 
> - Portage explicitly enforces it not being allowed anywhere else,
>   including in profiles that aren't marked as eapi 4

Portage already allows some characters in some places in EAPI="0" regardless of PMS :) .
Anyway I don't care.

> - The . isn't legal as the first character in a flag name. (Paludis has
>   been using [.foo=bar] and the like in user eapi contexts to allow
>   fancy queries on metadata. It would be a shame to have to change
>   that syntax just for some hypothetical possible use of . in use flag
>   names that looks really really weird anyway.)

No objection.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Thomas Sachau]

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

Am 25.10.2010 16:43, schrieb Fabio Erculiani:
> Implementing a feature to just satisfy your tiny, corner-case (how
> many people would take benefit out of it?) use case is just against
> any software engineering best practice, and it's a good path towards
> bloat and complexity. I think people can understand "python_abis_2_5"
> well enough, besides being happy that their app will KEEP working.
> 
> 

You are wrong at this part. Supporting dots in USE flags is not just a corner case for python
packages. I planned to suggest the same for a future EAPI, when i got my planned features for
multilib-portage done (which will then natively support the installation of packages for multiple
versions of those different lang packages (like python, ruby, php...). While it might be possible to
read and understand, that 2_5 is intended to be 2.5, it is much easier to understand and read, if
you just write 2.5.

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Petteri Räty]

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

On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> I would like to request that 2 additional features are added to EAPI="4".
> These features will be needed for further development of python.eclass.
> 
> 1. Support for "." characters in names of USE flags

Ideally we should have consistency across languages so if we go down
this road then for example ruby should eventually support it too. Ruby
people: can you provide your input.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Diego Elio Pettenò]

Il giorno lun, 25/10/2010 alle 19.23 +0300, Petteri Räty ha scritto:
> 
> Ideally we should have consistency across languages so if we go down
> this road then for example ruby should eventually support it too. Ruby
> people: can you provide your input. 

We don't really care since we use the Ruby basename, which is dot-free,
whatever the reason for that, may even be historical.

I don't think our users mind if it's ruby18 or ruby1.8… beside maybe the
Funtoo guys since Daniel decided to go with ruby1.9 breaking the
previous series of ruby16, ruby18 and ruby19.

But especially since _our_ system of dependencies is already in place,
we most certainly have no intention on going on to change it on all the
packages, so the '.' is totally useless for our scope.

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/

Re: [gentoo-dev] Extending EAPI="4"

[Matti Bickel]

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

On 10/25/2010 06:23 PM, Petteri Räty wrote:
> On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>> I would like to request that 2 additional features are added to EAPI="4".
>> These features will be needed for further development of python.eclass.
>>
>> 1. Support for "." characters in names of USE flags
> 
> Ideally we should have consistency across languages so if we go down
> this road then for example ruby should eventually support it too. Ruby
> people: can you provide your input.

PHP could potentially benefit from this, we currently (see
php-ext-source-r2.eclass) have to use "-" instead of the dot.
But to my eyes the ugliness is acceptable.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1214 bytes --]

2010-10-25 16:03:01 Ciaran McCreesh napisał(a):
> On Mon, 25 Oct 2010 15:56:18 +0200
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > 2010-10-25 15:42:00 Ciaran McCreesh napisał(a):
> > > On Mon, 25 Oct 2010 15:24:23 +0200
> > > Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > > > 1. Support for "." characters in names of USE flags
> > > 
> > > If you do this, you'll have to either convert everything using
> > > Python ABIs to EAPI 4 immediately, or have two sets of flag names.
> > > Won't users get confused if they have to set both python_abis_3_2
> > > (for EAPI < 4 packages) and python_abis_3.2 (for EAPI 4 packages)?
> > 
> > There won't be any such USE flags for EAPI <4.
> 
> Ok, that answers that objection. In that case I'd not be opposed to .
> being allowed *provided*:
> 
> - Portage explicitly enforces it not being allowed anywhere else,
>   including in profiles that aren't marked as eapi 4

I have implemented validation of syntax of USE flags in files in profiles:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=9e9c822aae0c3daab208175025b161d6d34877fe

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Zac Medico]

On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> use.unsatisfiable and package.use.unsatisfiable files would cause that `repoman` would treat
> given USE flags in the same way as masked USE flags. These files wouldn't affect behavior of
> `emerge`:
>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
>    and if optional dependencies controlled by this USE flag are already installed or satisfiable,
>    then `emerge` will allow to install given package.
>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
>    and if optional dependencies controlled by this USE flag cannot be satisfied (with current
>    settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then `emerge` will print
>    informative error message telling e.g. about a dependency masked by ~${ARCH} keyword.

Can't we print a "masked by ~${ARCH} keyword" message as you suggest,
even without the use.unsatisfiable data? If so, then isn't
use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
use.mask, so I don't see any value added.

As an alternative, I'd suggest an atom syntax extension to indicate that
a given atom is optional. For example, we could borrow the '?' character
from regular expression syntax, and append '?' to the right side of an
atom in order to indicate that it is an optional atom.

[1]
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93ee6a847be949e7752c3c052d3eb0619e408b43
-- 
Thanks,
Zac

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1494 bytes --]

2010-11-19 16:51:03 Zac Medico napisał(a):
> On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> > use.unsatisfiable and package.use.unsatisfiable files would cause that `repoman` would treat
> > given USE flags in the same way as masked USE flags. These files wouldn't affect behavior of
> > `emerge`:
> >  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
> >    and if optional dependencies controlled by this USE flag are already installed or satisfiable,
> >    then `emerge` will allow to install given package.
> >  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
> >    and if optional dependencies controlled by this USE flag cannot be satisfied (with current
> >    settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then `emerge` will print
> >    informative error message telling e.g. about a dependency masked by ~${ARCH} keyword.
> 
> Can't we print a "masked by ~${ARCH} keyword" message as you suggest,
> even without the use.unsatisfiable data? If so, then isn't
> use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
> use.mask, so I don't see any value added.

repoman sometimes needs to allow stable packages to have optional dependencies on unstable
packages (usually until these packages are stabilized). My patch implements this functionality
for repoman.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Zac Medico]

On 11/28/2010 10:15 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-11-19 16:51:03 Zac Medico napisał(a):
>> On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
>>> use.unsatisfiable and package.use.unsatisfiable files would cause that `repoman` would treat
>>> given USE flags in the same way as masked USE flags. These files wouldn't affect behavior of
>>> `emerge`:
>>>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
>>>    and if optional dependencies controlled by this USE flag are already installed or satisfiable,
>>>    then `emerge` will allow to install given package.
>>>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
>>>    and if optional dependencies controlled by this USE flag cannot be satisfied (with current
>>>    settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then `emerge` will print
>>>    informative error message telling e.g. about a dependency masked by ~${ARCH} keyword.
>>
>> Can't we print a "masked by ~${ARCH} keyword" message as you suggest,
>> even without the use.unsatisfiable data? If so, then isn't
>> use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
>> use.mask, so I don't see any value added.
> 
> repoman sometimes needs to allow stable packages to have optional dependencies on unstable
> packages (usually until these packages are stabilized). My patch implements this functionality
> for repoman.

It seems like you're trying to bypass an important function of repoman
though. The idea is that repoman is supposed to protect users from
experiencing unsatisfiable dependencies of this sort, and use.mask
accomplishes that. With your use.unsatisfiable patch, it makes repoman
quiet, while leaving users unprotected from unsatisfied dependencies.
-- 
Thanks,
Zac

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 2579 bytes --]

2010-11-28 20:59:05 Zac Medico napisał(a):
> On 11/28/2010 10:15 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> > 2010-11-19 16:51:03 Zac Medico napisał(a):
> >> On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> >>> use.unsatisfiable and package.use.unsatisfiable files would cause that `repoman` would treat
> >>> given USE flags in the same way as masked USE flags. These files wouldn't affect behavior of
> >>> `emerge`:
> >>>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
> >>>    and if optional dependencies controlled by this USE flag are already installed or satisfiable,
> >>>    then `emerge` will allow to install given package.
> >>>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
> >>>    and if optional dependencies controlled by this USE flag cannot be satisfied (with current
> >>>    settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then `emerge` will print
> >>>    informative error message telling e.g. about a dependency masked by ~${ARCH} keyword.
> >>
> >> Can't we print a "masked by ~${ARCH} keyword" message as you suggest,
> >> even without the use.unsatisfiable data? If so, then isn't
> >> use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
> >> use.mask, so I don't see any value added.
> > 
> > repoman sometimes needs to allow stable packages to have optional dependencies on unstable
> > packages (usually until these packages are stabilized). My patch implements this functionality
> > for repoman.
> 
> It seems like you're trying to bypass an important function of repoman
> though. The idea is that repoman is supposed to protect users from
> experiencing unsatisfiable dependencies of this sort, and use.mask
> accomplishes that.

If "python_abis_2.7", "python_abis_3.1" and "python_abis_3.2" USE flags are masked using use.mask
on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these architectures, then
majority of reverse dependencies of Python wouldn't be tested with new versions of Python.

Example {,R}DEPEND:
  python_abis_2.4? ( dev-lang/python:2.4 )
  python_abis_2.5? ( dev-lang/python:2.5 )
  python_abis_2.6? ( dev-lang/python:2.6 )
  python_abis_2.7? ( dev-lang/python:2.7 )
  python_abis_3.0? ( dev-lang/python:3.0 )
  python_abis_3.1? ( dev-lang/python:3.1 )
  python_abis_3.2? ( dev-lang/python:3.2 )
  python_abis_2.5-jython? ( dev-java/jython:2.5 )

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Zac Medico]

On 11/28/2010 12:07 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-11-28 20:59:05 Zac Medico napisał(a):
>> It seems like you're trying to bypass an important function of repoman
>> though. The idea is that repoman is supposed to protect users from
>> experiencing unsatisfiable dependencies of this sort, and use.mask
>> accomplishes that.
> 
> If "python_abis_2.7", "python_abis_3.1" and "python_abis_3.2" USE flags are masked using use.mask
> on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these architectures, then
> majority of reverse dependencies of Python wouldn't be tested with new versions of Python.
> 
> Example {,R}DEPEND:
>   python_abis_2.4? ( dev-lang/python:2.4 )
>   python_abis_2.5? ( dev-lang/python:2.5 )
>   python_abis_2.6? ( dev-lang/python:2.6 )
>   python_abis_2.7? ( dev-lang/python:2.7 )
>   python_abis_3.0? ( dev-lang/python:3.0 )
>   python_abis_3.1? ( dev-lang/python:3.1 )
>   python_abis_3.2? ( dev-lang/python:3.2 )
>   python_abis_2.5-jython? ( dev-java/jython:2.5 )

It seems like the problem here is that we don't have separate profiles
for stable and unstable keywords. The obvious solution would be to have
separate profiles, mask the flags in the stable profiles, and unmask the
flags in the unstable profiles. That way, repoman would continue to
protect stable profile users from unsatisfiable dependencies, without
unnecessarily masking those choices from unstable profile users.
-- 
Thanks,
Zac

Re: [gentoo-dev] Extending EAPI="4"

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1868 bytes --]

2010-11-28 21:30:47 Zac Medico napisał(a):
> On 11/28/2010 12:07 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> > 2010-11-28 20:59:05 Zac Medico napisał(a):
> >> It seems like you're trying to bypass an important function of repoman
> >> though. The idea is that repoman is supposed to protect users from
> >> experiencing unsatisfiable dependencies of this sort, and use.mask
> >> accomplishes that.
> > 
> > If "python_abis_2.7", "python_abis_3.1" and "python_abis_3.2" USE flags are masked using use.mask
> > on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these architectures, then
> > majority of reverse dependencies of Python wouldn't be tested with new versions of Python.
> > 
> > Example {,R}DEPEND:
> >   python_abis_2.4? ( dev-lang/python:2.4 )
> >   python_abis_2.5? ( dev-lang/python:2.5 )
> >   python_abis_2.6? ( dev-lang/python:2.6 )
> >   python_abis_2.7? ( dev-lang/python:2.7 )
> >   python_abis_3.0? ( dev-lang/python:3.0 )
> >   python_abis_3.1? ( dev-lang/python:3.1 )
> >   python_abis_3.2? ( dev-lang/python:3.2 )
> >   python_abis_2.5-jython? ( dev-java/jython:2.5 )
> 
> It seems like the problem here is that we don't have separate profiles
> for stable and unstable keywords. The obvious solution would be to have
> separate profiles, mask the flags in the stable profiles, and unmask the
> flags in the unstable profiles. That way, repoman would continue to
> protect stable profile users from unsatisfiable dependencies, without
> unnecessarily masking those choices from unstable profile users.

I would prefer small number of additional files instead of huge proliferation of profiles.
You also suggested using EAPI="4"-specific profiles instead of EAPI-versioned files, so eventually
we might have about 4 times more profiles :) .

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Extending EAPI="4"

[Zac Medico]

On 11/28/2010 01:56 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-11-28 21:30:47 Zac Medico napisał(a):
>> It seems like the problem here is that we don't have separate profiles
>> for stable and unstable keywords. The obvious solution would be to have
>> separate profiles, mask the flags in the stable profiles, and unmask the
>> flags in the unstable profiles. That way, repoman would continue to
>> protect stable profile users from unsatisfiable dependencies, without
>> unnecessarily masking those choices from unstable profile users.
> 
> I would prefer small number of additional files instead of huge proliferation of profiles.
> You also suggested using EAPI="4"-specific profiles instead of EAPI-versioned files, so eventually
> we might have about 4 times more profiles :) .

It would only be 2 times in profiles.desc, since my suggestion regarding
the EAPI 4 profiles was to deprecate the older profiles and drop them
from profiles.desc.
-- 
Thanks,
Zac

Re: [gentoo-dev] Extending EAPI="4"

[Petteri Räty]

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

On 11/28/2010 11:56 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>>
>> It seems like the problem here is that we don't have separate profiles
>> for stable and unstable keywords. The obvious solution would be to have
>> separate profiles, mask the flags in the stable profiles, and unmask the
>> flags in the unstable profiles. That way, repoman would continue to
>> protect stable profile users from unsatisfiable dependencies, without
>> unnecessarily masking those choices from unstable profile users.
> 
> I would prefer small number of additional files instead of huge proliferation of profiles.
> You also suggested using EAPI="4"-specific profiles instead of EAPI-versioned files, so eventually
> we might have about 4 times more profiles :) .
> 

There's no requirement to keep old profiles around indefinitely. Old
profiles will eventually go away once the new ones are the recommended
option. As for this particular case I haven't really taken a close
enough opinion to say if new profiles make the best sense or not.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]