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.
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
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
(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.
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.)
(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.
(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...
(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.
(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.
(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.
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.
(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.
(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
(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.
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
This is in the master branch now: https://github.com/gentoo/portage/commit/605846a0b98869c9d1cbf19660969fb24e5c680b
Released in portage-2.2.16
