[gentoo-dev] eapi files and profiles

[gentoo-dev] eapi files and profiles

[Samuli Suominen]

So I was told Council needs to approve inheritance of eapi files from
parent profiles?

I'm not sure why, because we shouldn't have any files in default/linux/
which was decided long ago when the new profiles was introduced...

gentoo-x86/profiles/default/linux $ find ./ -name eapi | wc -l
63

That's 63 duplicated files. We should only have one releases/10.0/eapi
file, and others wouldn't be required as it would cover all the 10.0
profiles.

See, http://bugs.gentoo.org/288320

Can we get a decision on this soon, so we can drop the duplication for
10.1 (or whatever the name for next profile set will be called) ?

Re: [gentoo-dev] eapi files and profiles

[Ulrich Mueller]

>>>>> On Fri, 23 Oct 2009, Samuli Suominen wrote:

> So I was told Council needs to approve inheritance of eapi files
> from parent profiles?

Doesn't <http://bugs.gentoo.org/288320#c7> cover this? Why would you
need explicit inheritance?

And which EAPI should be taken, if you have more than one parent
profile? (All of them? Can a profile have multiple EAPIs?)

Ulrich

Re: [gentoo-dev] eapi files and profiles

[Petteri Räty]

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

Ulrich Mueller wrote:
>>>>>> On Fri, 23 Oct 2009, Samuli Suominen wrote:
> 
>> So I was told Council needs to approve inheritance of eapi files
>> from parent profiles?
> 
> Doesn't <http://bugs.gentoo.org/288320#c7> cover this? Why would you
> need explicit inheritance?
> 

Well technically you still shouldn't add EAPI 2 atoms to the child
profiles without them being marked with the appropriate eapi file entry.
Do all the levels of 10.0 profiles use EAPI 2 entries?

Regards,
Petteri


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

Re: [gentoo-dev] eapi files and profiles

[Ciaran McCreesh]

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

On Fri, 23 Oct 2009 23:26:47 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Well technically you still shouldn't add EAPI 2 atoms to the child
> profiles without them being marked with the appropriate eapi file
> entry. Do all the levels of 10.0 profiles use EAPI 2 entries?

Down that way leads madness...

Mark any profile directory that itself uses EAPI 1 (there's nothing that
makes sense EAPI 2-wise for profiles) as EAPI 1. Leave any other
directory alone.

Doing it any other way requires far too much careful attention.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] eapi files and profiles

[Ciaran McCreesh]

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

On Fri, 23 Oct 2009 11:24:27 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> So I was told Council needs to approve inheritance of eapi files from
> parent profiles?

As a full explanation of why this idea sucks, since some people have
asked:

You need to decide which way eapi inherits go. Are you saying that any
profile directory with a parent using EAPI X is itself EAPI X? If so,
the implications are:

* that we can't change the format of the parent file ever (and we have
  done so in the past)

* that it gets a lot harder to remove certain syntax in newer EAPIs.
  For example, say we want to replace =...* with ranged dependencies in
  EAPI 4. Then you can't change a profile directory to use EAPI 4
  without checking that everything that uses that directory doesn't
  make use of =...*.

Or are you saying that the package manager should use the eapi it picks
up for any parents it follows? If so, the implications are:

* that removing =...* in EAPI 4 (for example) becomes impossible,
  because it would be impossible to use that syntax in high level
  profiles that might be inherited by profiles using EAPI 4.

Either way, putting eapi files in any directory that itself
specifically needs it is a heck of a lot easier for everyone.

On top of that, if you do change it, there's the usual year wait before
you can use it, since current package managers don't inherit eapis.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] eapi files and profiles

[Brian Harring]

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

On Fri, Oct 23, 2009 at 11:24:27AM +0300, Samuli Suominen wrote:
> So I was told Council needs to approve inheritance of eapi files from
> parent profiles?
> 
> I'm not sure why, because we shouldn't have any files in default/linux/
> which was decided long ago when the new profiles was introduced...
> 
> gentoo-x86/profiles/default/linux $ find ./ -name eapi | wc -l
> 63
> 
> That's 63 duplicated files. We should only have one releases/10.0/eapi
> file, and others wouldn't be required as it would cover all the 10.0
> profiles.
> 
> See, http://bugs.gentoo.org/288320
> 
> Can we get a decision on this soon, so we can drop the duplication for
> 10.1 (or whatever the name for next profile set will be called) ?

This is going to break compatibility for pkgcore at least- we limit 
what forms of atoms are allowed dependant on the eapi of that profile 
node.  I'd hope paludis does the same- I know portage doesn't however.

Further... the more I think about this, the more I'm inclined to think 
this will blow someones foot off.  If the eapi is inherited from the 
parent, what happens when the parent switches to an EAPI that changes 
the atom parsing rules?  Specifically, *restricts* the atom parsing 
rules?

Say that we got rid of the ~ operator w/in EAPI4.  '~' is completely 
valid in the default EAPI=0; if the parent profile switches to EAPI4, 
it suddenly breaks parsing of any defaulted EAPI that used revision 
matching.

So... inheritance sucks.  It gets worse when you have user 
configuration (custom profiles) inheriting from gentoo-x86 provided 
profiles- I'd expect user config to use things that are more cutting 
edge.

Alternative approach- the default EAPI currently is 0, and isn't 
overridable.  Add a file into the base of the profile directory that 
specifies the default EAPI.

Via that, you can do your file optimizations- if the majority of 
profile nodes are eapi=2, then you set the default to 2 and update the 
nodes that were reliant on the previous default.

Note this still requires having this change sit in the tree for a 
while for compatibilty reasons- but it is a good idea regardless to 
avoid requiring EAPI to be specified for every single profile node 
when we've hit EAPI=7....

~harring

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