Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 532670 - sys-apps/portage: allow override of default profile EAPI, so it defaults to something other than EAPI 0
Summary: sys-apps/portage: allow override of default profile EAPI, so it defaults to s...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Configuration (show other bugs)
Hardware: All All
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 484436
  Show dependency tree
 
Reported: 2014-12-16 01:50 UTC by Zac Medico
Modified: 2015-03-04 21:27 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zac Medico gentoo-dev 2014-12-16 01:50:42 UTC
Organizations that maintain their own profiles, in separate repositories from Gentoo, typically want to use EAPI 5 for all of their profiles. In order to accomplish this, they currently have to create an eapi file in each and every directory of their profiles.

It would be much more convenient if there was a way to specify the default profile EAPI for all profiles in the repository. For example, setting "profile-formats = eapi-5" in metdatadata/layout.conf will cause all profiles that do not contain an eapi file to default to EAPI 5 instead of EAPI 0.
Comment 1 Zac Medico gentoo-dev 2014-12-16 02:02:55 UTC
I have a patch in this branch:

	https://github.com/zmedico/portage/tree/profile-formats-eapi-x

I've posted it for review here:

	http://thread.gmane.org/gmane.linux.gentoo.portage.devel/5010
Comment 2 Ulrich Müller gentoo-dev 2014-12-16 06:20:40 UTC
This contradicts PMS:
"If no eapi file is present, EAPI 0 shall be used."
http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-350004.4
Comment 3 Zac Medico gentoo-dev 2014-12-16 06:24:04 UTC
(In reply to Ulrich Müller from comment #2)
> This contradicts PMS:
> "If no eapi file is present, EAPI 0 shall be used."
> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-350004.4

Like bug 532224, this one is outside the scope of PMS, because the change in behavior is hidden behind a metadata/layout.conf profile-formats flag.
Comment 4 Arfrever Frehtes Taifersar Arahesis 2014-12-16 12:17:11 UTC
I would prefer a separate attribute in layout.conf instead of extending profile-formats attribute.

Example: http://git.exherbo.org/arbor.git/tree/metadata/layout.conf?id=8c51549a49f318cbe56d077f63f2cd3b1f7886e3
  eapi_when_unknown = exheres-0
  eapi_when_unspecified = exheres-0
  profile_eapi_when_unspecified = exheres-0


I would prefer a separate attribute (e.g. "profile_eapi_when_unspecified") of portage.repository.config.RepoConfig instances instead of adding another meaning to "eapi" attribute. ("eapi" attribute currently specifies only EAPI of repository-level configuration.)
Comment 5 Tim Harder gentoo-dev 2014-12-16 16:57:32 UTC
(In reply to Zac Medico from comment #3)
> (In reply to Ulrich Müller from comment #2)
> > This contradicts PMS:
> > "If no eapi file is present, EAPI 0 shall be used."
> > http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-350004.4
> 
> Like bug 532224, this one is outside the scope of PMS, because the change in
> behavior is hidden behind a metadata/layout.conf profile-formats flag.

This is tricky because the effects won't be hidden for PMs not implementing this extension. For example, say you have a repo where you have eapi files everywhere specifying EAPI 5 and then drop them all after enabling this extension. Now only portage thinks that all profiles are EAPI 5 compliant while other PMs probably think they are EAPI 0 profiles causing issues if you have settings reliant on > EAPI 0 behavior such as slot deps or stable forced/masked use flag settings. 

Also, I agree with comment 4 in that this should be put in another attribute and not into profile-formats.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-16 17:43:38 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #4)
> I would prefer a separate attribute in layout.conf instead of extending
> profile-formats attribute.
> 
> Example:
> http://git.exherbo.org/arbor.git/tree/metadata/layout.
> conf?id=8c51549a49f318cbe56d077f63f2cd3b1f7886e3
>   eapi_when_unknown = exheres-0

How does that make any sense? How can you assume some EAPI when you know that you don't know how to handle the correct EAPI...
Comment 7 Zac Medico gentoo-dev 2014-12-16 17:46:47 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #4)
> I would prefer a separate attribute in layout.conf instead of extending
> profile-formats attribute.

I think it's better to leverage profile-formats for this, since existing package managers are already aware of the profile-formats field, and its extensible nature makes it suitable for extensions such as this.

If we really needed separate attributes, then I would also flag them in profile-formats field, so that existing package managers with profile-formats awareness would produce a warning.

> I would prefer a separate attribute (e.g. "profile_eapi_when_unspecified")
> of portage.repository.config.RepoConfig instances instead of adding another
> meaning to "eapi" attribute. ("eapi" attribute currently specifies only EAPI
> of repository-level configuration.)

This attribute was not used anywhere in portage code, and I think the new meaning is more useful and more intuitive.

(In reply to Tim Harder from comment #5)
> (In reply to Zac Medico from comment #3)
> > Like bug 532224, this one is outside the scope of PMS, because the change in
> > behavior is hidden behind a metadata/layout.conf profile-formats flag.
> 
> This is tricky because the effects won't be hidden for PMs not implementing
> this extension. For example, say you have a repo where you have eapi files
> everywhere specifying EAPI 5 and then drop them all after enabling this
> extension. Now only portage thinks that all profiles are EAPI 5 compliant
> while other PMs probably think they are EAPI 0 profiles causing issues if
> you have settings reliant on > EAPI 0 behavior such as slot deps or stable
> forced/masked use flag settings. 

The whole point of profile-formats is to allow the freedom to do things like this. I'm not suggesting that we use "profile-formats = eapi-5" in the "gentoo" tree. Anyone that would like to deploy a repository with "profile-formats = eapi-5" really ought to consider how it's going to affect the consumers of their repository. For example, they might leave the eapi files in place for a period of time, until consumers have had a sufficient window of time to upgrade their package manager.

> Also, I agree with comment 4 in that this should be put in another attribute
> and not into profile-formats.

As said in reply to Arfrever, if we really needed a separate attribute, then I would prefer to flag it in profile-formats anyway. I'm pretty happy with the current implementation.
Comment 8 Arfrever Frehtes Taifersar Arahesis 2014-12-16 18:30:54 UTC
(In reply to Zac Medico from comment #7)
> > I would prefer a separate attribute (e.g. "profile_eapi_when_unspecified")
> > of portage.repository.config.RepoConfig instances instead of adding another
> > meaning to "eapi" attribute. ("eapi" attribute currently specifies only EAPI
> > of repository-level configuration.)
> 
> This attribute was not used anywhere in portage code, and I think the new
> meaning is more useful and more intuitive.

Some calls to read_corresponding_eapi_file() could be replaced by usage of eapi of portage.repository.config.RepoConfig instance.
I have an unrelated plan of allowing to specify EAPI of repository-level configuration in layout.conf instead of separate "eapi" file. Implementation of this plan would require usage of "eapi" attribute (or a new attribute) of portage.repository.config.RepoConfig instances.
Comment 9 Arfrever Frehtes Taifersar Arahesis 2014-12-16 18:37:52 UTC
(In reply to Michał Górny from comment #6)
> (In reply to Arfrever Frehtes Taifersar Arahesis from comment #4)
> > Example:
> > http://git.exherbo.org/arbor.git/tree/metadata/layout.
> > conf?id=8c51549a49f318cbe56d077f63f2cd3b1f7886e3
> >   eapi_when_unknown = exheres-0
> 
> How does that make any sense? How can you assume some EAPI when you know
> that you don't know how to handle the correct EAPI...

Existence of it is probably due to lack of parsing of EAPI= line in exheres.
http://paludis.exherbo.org/configuration/repositories/e.html :

"eapi_when_unknown
    The EAPI to use when a package's EAPI is unknown (e.g. before it has
    been sourced to generate its metadata, if it does not use an EAPI
    filename suffix). Optional, generally set by the distribution.

eapi_when_unspecified
    The EAPI to use when a package does not specify an EAPI, either
    explicitly or by suffix. Optional, generally set by the distribution.

profile_eapi_when_unspecified
    The EAPI to use for profiles when unspecified. Optional, generally
    set by the distribution."

Only "eapi_when_unspecified" and "profile_eapi_when_unspecified" might be useful in Gentoo, but I would suggest to use names "default_ebuild_eapi" and "default_profile_eapi" in Gentoo.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-16 18:40:25 UTC
And I would suggest using the same names if we're using the same configuration file name.

Zac, if you really want to abuse profile-formats, then I think it would be better to have a single flag stating that one uses the special EAPI variables.
Comment 11 Zac Medico gentoo-dev 2014-12-16 18:54:05 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #8)
> Some calls to read_corresponding_eapi_file() could be replaced by usage of
> eapi of portage.repository.config.RepoConfig instance.
> I have an unrelated plan of allowing to specify EAPI of repository-level
> configuration in layout.conf instead of separate "eapi" file. Implementation
> of this plan would require usage of "eapi" attribute (or a new attribute) of
> portage.repository.config.RepoConfig instances.

I'd prefer to use a different attribute for that purpose, perhaps named profiles_eapi or something like that.

(In reply to Michał Górny from comment #10)
> Zac, if you really want to abuse profile-formats, then I think it would be
> better to have a single flag stating that one uses the special EAPI
> variables.

If that's what everybody insists on, then I can go along with that. We can re-use Exherbo's profile_eapi_when_unspecified attribute, and flag it as "profile-default-eapi" in profile-formats.
Comment 12 Arfrever Frehtes Taifersar Arahesis 2014-12-16 19:09:53 UTC
(In reply to Zac Medico from comment #11)
> If that's what everybody insists on, then I can go along with that. We can
> re-use Exherbo's profile_eapi_when_unspecified attribute, and flag it as
> "profile-default-eapi" in profile-formats.

Maybe better this in layout.conf?:

profile-formats = profile-default-eapi
profile-default-eapi = 5
Comment 13 Zac Medico gentoo-dev 2014-12-16 19:54:15 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12)
> Maybe better this in layout.conf?:
> 
> profile-formats = profile-default-eapi
> profile-default-eapi = 5

Honestly, I don't care what names we go with. Since Paludis has already supported profile_eapi_when_unspecified for years though, it would be nice to re-use that for the sake of consistency.
Comment 14 Zac Medico gentoo-dev 2014-12-17 19:42:55 UTC
There's a new patch which implements profile_eapi_when_unspecified in this branch:

https://github.com/zmedico/portage/tree/profile-formats-profile-default-eapi

I've posted it for review here:

http://thread.gmane.org/gmane.linux.gentoo.portage.devel/5014
Comment 15 Zac Medico gentoo-dev 2014-12-31 04:43:43 UTC
This is in the master branch now:

https://github.com/gentoo/portage/commit/605846a0b98869c9d1cbf19660969fb24e5c680b
Comment 16 Brian Dolbec gentoo-dev 2015-03-04 21:27:32 UTC
Released in portage-2.2.16