FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-18-2010, 12:45 AM
Arfrever Frehtes Taifersar Arahesis
 
Default Summary of suggested new features in EAPI="4"

This is the summary of some problems and suggested new features in EAPI="4", which would solve
these problems.

================================================== ==============================================

Problem #1: USE flags cannot contain "." characters.

The following solutions have been suggested:
- Add support for "." characters in USE flags in EAPI="4".

================================================== ==============================================

Problem #2: Files in profiles cannot use features from newer EAPIs.

The following solutions have been suggested:
- Add support for files with "-${EAPI}" extension in EAPI="4". These files would use EAPI
specified in their filenames instead of EAPI of profile.
Example files:
package.mask-${EAPI}
package.use-${EAPI}
package.provided-${EAPI}
use.force-${EAPI}
use.mask-${EAPI}
package.use.force-${EAPI}
package.use.mask-${EAPI}
packages-${EAPI}
virtuals-${EAPI}
- Create new profiles using EAPI="4", remove all older profiles from profiles.desc so that
repoman doesn't check older profiles, and deprecate older profiles.

Council should choose one of these solutions.

================================================== ==============================================

Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable
packages (usually until these packages are stabilized).

Example of the problem:
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 won't be tested with new
versions of Python.

The following solutions have been suggested:
- Add support for use.unsatisfiable and package.use.unsatisfiable files in profiles in
EAPI="4". These files would cause that repoman would allow optional dependencies on
packages potentially unsatisfiable in some configurations (e.g. on stable-only systems).
- Create separate profiles for stable and unstable keywords. USE flags would be masked in
stable profiles and unmasked in unstable profiles.

Council should choose one of these solutions.

================================================== ==============================================

There are already existing patches for Portage, which implement these solutions, which are
suggested new features in EAPI="4".

--
Arfrever Frehtes Taifersar Arahesis
 
Old 12-18-2010, 01:48 AM
Donnie Berkholz
 
Default Summary of suggested new features in EAPI="4"

On 02:45 Sat 18 Dec , Arfrever Frehtes Taifersar Arahesis wrote:
> Problem #1: USE flags cannot contain "." characters.

This isn't a problem, it's an arbitrary statement of an antifeature. My
understanding of the actual problem here is that you want to have some
sort of USE flags for various Python versions with names containing
periods, for usability. Perhaps you could expand on exactly what you
want to do, so we can work together to figure out whether this is the
best route to solve your problem.

If the problem is handling which Python versions to build modules for,
I'm wondering whether enhancing the eselect module to select *multiple*
preferred versions might not be a better solution than EAPI changes.

We've been having the same discussion for Fortran90 modules, and George
Shapovalov mentioned that this is how he handled things for Ada (see
gnat-related eclass/eselect mod).

> ================================================== ==============================================
>
> Problem #2: Files in profiles cannot use features from newer EAPIs.

Could you explain how the eapi file in profiles does not address this?
The 10.0 profiles are using it already with EAPI=2. I'll paste the
description from the PMS to make it easier for anyone following along:

5.2.2 The eapi file

A profile directory may contain an eapi file. This file, if it exists,
must contain a single line with the name of an EAPI. This specifies the
EAPI to use when handling the directory in question; a package manager
must not attempt to use any profile using a directory which requires an
EAPI it does not support. If no eapi file is present, EAPI 0 shall be
used. The EAPI is not inherited via the parent file.

> ================================================== ==============================================
>
> Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable
> packages (usually until these packages are stabilized).

This seems useful at first glance, but I'm wondering how big of a
problem it really is and whether this solution is a bit overarchitected.

> Example of the problem:
> 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 won't be tested with new versions of
> Python.

Why does that have to be the case? Why not unmask them earlier but only
make them available to ~arch ebuilds?

I don't know of anyone who's actually done this, but setting IUSE based
on ACCEPT_KEYWORDS being ~arch should be possible. There may be better
or easier solutions.

> The following solutions have been suggested:
>
> - Add support for use.unsatisfiable and package.use.unsatisfiable files in profiles in
> EAPI="4". These files would cause that repoman would allow optional
> dependencies on packages potentially unsatisfiable in some
> configurations (e.g. on stable-only systems).
> - Create separate profiles for stable and unstable keywords. USE flags
> would be masked in stable profiles and unmasked in unstable profiles.
>
> Council should choose one of these solutions.

--
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
 
Old 12-18-2010, 02:41 AM
Arfrever Frehtes Taifersar Arahesis
 
Default Summary of suggested new features in EAPI="4"

2010-12-18 03:48:26 Donnie Berkholz napisaƂ(a):
> On 02:45 Sat 18 Dec , Arfrever Frehtes Taifersar Arahesis wrote:
> > Problem #1: USE flags cannot contain "." characters.
>
> This isn't a problem, it's an arbitrary statement of an antifeature. My
> understanding of the actual problem here is that you want to have some
> sort of USE flags for various Python versions with names containing
> periods, for usability. Perhaps you could expand on exactly what you
> want to do, so we can work together to figure out whether this is the
> best route to solve your problem.
>
> If the problem is handling which Python versions to build modules for,
> I'm wondering whether enhancing the eselect module to select multiple
> preferred versions might not be a better solution than EAPI changes.

USE flags would allow to use USE dependencies to ensure that dependencies of given package
have been installed for required Python versions.

> > ================================================== ==============================================
> >
> > Problem #2: Files in profiles cannot use features from newer EAPIs.
>
> Could you explain how the eapi file in profiles does not address this?
> The 10.0 profiles are using it already with EAPI=2.

I would like to use EAPI="4"-specific syntax in a file in base profile (or somewhere else) to
affect all profiles. If I have to rely on "eapi" files, then all non-deprecated profiles
checked by repoman would have to use EAPI >=4.

> > ================================================== ==============================================
> >
> > Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable
> > packages (usually until these packages are stabilized).
>
> This seems useful at first glance, but I'm wondering how big of a
> problem it really is and whether this solution is a bit overarchitected.
>
> > Example of the problem:
> > 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 won't be tested with new versions of
> > Python.
>
> Why does that have to be the case? Why not unmask them earlier but only
> make them available to ~arch ebuilds?

There are already hundreds of stable ebuilds, which support unstable Python 2.7 (without
explicit optional dependency on Python 2.7). The solution to problem #3 shouldn't require
any changes in ebuilds.

> I don't know of anyone who's actually done this, but setting IUSE based
> on ACCEPT_KEYWORDS being ~arch should be possible.

It would break invariance of metadata.

--
Arfrever Frehtes Taifersar Arahesis
 
Old 12-18-2010, 08:57 AM
Fabian Groffen
 
Default Summary of suggested new features in EAPI="4"

On 18-12-2010 02:45:06 +0100, Arfrever Frehtes Taifersar Arahesis wrote:
>
> Problem #1: USE flags cannot contain "." characters.
>
> The following solutions have been suggested:
> - Add support for "." characters in USE flags in EAPI="4".

Like Donnie said, this feels like a purely cosmetic change. I think
that alone is not a good reason to do this.

> Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable
> packages (usually until these packages are stabilized).
>
> Example of the problem:
> 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 won't be tested with new
> versions of Python.

I don't see the problem here actually. As soon as you're going to allow
stable and unstable to be mixed, the concept of stable isn't worth much
any more, IMO. If you want to have some experimental feature in some
package, it can never be stable, unless it is e.g. USE-masked, and
unmasking of the right package(s) is left as an excercise for the
user.

Your Python example only indicates to me how much of a mess it has
actually become. For most other packages, it is quite normal that a new
version is "untested" until it is stabilised, which means unstable users
are the ones to find the problems, if any. The maintainer (and to an
extent the arch teams) of course has a leading role in this.


--
Fabian Groffen
Gentoo on a different level
 
Old 12-18-2010, 11:32 AM
Zac Medico
 
Default Summary of suggested new features in EAPI="4"

On 12/18/2010 01:57 AM, Fabian Groffen wrote:
> On 18-12-2010 02:45:06 +0100, Arfrever Frehtes Taifersar Arahesis wrote:
>>
>> Problem #1: USE flags cannot contain "." characters.
>>
>> The following solutions have been suggested:
>> - Add support for "." characters in USE flags in EAPI="4".
>
> Like Donnie said, this feels like a purely cosmetic change. I think
> that alone is not a good reason to do this.
>
>> Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable
>> packages (usually until these packages are stabilized).
>>
>> Example of the problem:
>> 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 won't be tested with new
>> versions of Python.
>
> I don't see the problem here actually. As soon as you're going to allow
> stable and unstable to be mixed, the concept of stable isn't worth much
> any more, IMO. If you want to have some experimental feature in some
> package, it can never be stable, unless it is e.g. USE-masked, and
> unmasking of the right package(s) is left as an excercise for the
> user.
>
> Your Python example only indicates to me how much of a mess it has
> actually become. For most other packages, it is quite normal that a new
> version is "untested" until it is stabilised, which means unstable users
> are the ones to find the problems, if any. The maintainer (and to an
> extent the arch teams) of course has a leading role in this.

I think the "separate profiles for stable and unstable keywords"
approach is a clear winner here. With separate stable and unstable
profiles, unstable users don't have to do any unmasking themselves. When
it comes time to migrate things to stable, the arch teams simply update
the stable profiles to behave like the unstable profiles. This approach
also protects stable users from experiencing "unsatisfied dependencies"
that the *.unsatisfiable approach would expose them to.
--
Thanks,
Zac
 
Old 12-18-2010, 09:21 PM
Ciaran McCreesh
 
Default Summary of suggested new features in EAPI="4"

On Fri, 17 Dec 2010 20:48:26 -0600
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> I don't know of anyone who's actually done this, but setting IUSE
> based on ACCEPT_KEYWORDS being ~arch should be possible. There may be
> better or easier solutions.

Uhm... IUSE has to be metadata-invariant.

--
Ciaran McCreesh
 
Old 12-20-2010, 02:41 AM
Donnie Berkholz
 
Default Summary of suggested new features in EAPI="4"

On 22:21 Sat 18 Dec , Ciaran McCreesh wrote:
> On Fri, 17 Dec 2010 20:48:26 -0600
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > I don't know of anyone who's actually done this, but setting IUSE
> > based on ACCEPT_KEYWORDS being ~arch should be possible. There may be
> > better or easier solutions.
>
> Uhm... IUSE has to be metadata-invariant.

Oh, so we need to have USE dependencies in IUSE. =)

--
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
 

Thread Tools




All times are GMT. The time now is 07:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org