* Re: [gentoo-dev] eapi files and profiles
2009-10-23 8:24 [gentoo-dev] eapi files and profiles Samuli Suominen
@ 2009-10-23 10:20 ` Ulrich Mueller
2009-10-23 20:26 ` Petteri Räty
2009-10-23 20:37 ` Ciaran McCreesh
2009-10-23 21:04 ` Brian Harring
2 siblings, 1 reply; 6+ messages in thread
From: Ulrich Mueller @ 2009-10-23 10:20 UTC (permalink / raw
To: gentoo-dev
>>>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] eapi files and profiles
2009-10-23 8:24 [gentoo-dev] eapi files and profiles Samuli Suominen
2009-10-23 10:20 ` Ulrich Mueller
@ 2009-10-23 20:37 ` Ciaran McCreesh
2009-10-23 21:04 ` Brian Harring
2 siblings, 0 replies; 6+ messages in thread
From: Ciaran McCreesh @ 2009-10-23 20:37 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] eapi files and profiles
2009-10-23 8:24 [gentoo-dev] eapi files and profiles Samuli Suominen
2009-10-23 10:20 ` Ulrich Mueller
2009-10-23 20:37 ` Ciaran McCreesh
@ 2009-10-23 21:04 ` Brian Harring
2 siblings, 0 replies; 6+ messages in thread
From: Brian Harring @ 2009-10-23 21:04 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread