GLEP:55
Title:Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Version:1.1
Last-Modified:2008/01/05 02:36:35
Author:Piotr JaroszyƄski <peper at gentoo.org>
Status:Draft
Type:Standards Track
Content-Type:text/x-rst
Created:17-Dec-2007
Post-History:17-Dec-2007, 22-Dec-2007

Contents

"A little learning is a dangerous thing; drink deep, or taste not the Pierian spring: there shallow draughts intoxicate the brain, and drinking largely sobers us again."

—Alexander Pope, An Essay on Criticism

Abstract

This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1).

Problem

The current way of specifying the EAPI in ebuilds is flawed. In order to get the EAPI the package manager needs to source the ebuild, which itself needs the EAPI in the first place. Otherwise it imposes a serious limitation, namely every ebuild, using any of the future EAPIs, will have to be source'able by old package managers and hence there is no way to do any of the following:

Abstract solution

A solution to this problem has to lift those limitations and the only way to do it is to make the EAPI of an ebuild available to the package managers in a way that doesn't require them to source the ebuild. Another important requirement is for the solution to be backward compatible, which has the pleasant side-effect of making the solution applicable in the Gentoo tree right away. Opposed to waiting an arbitrary amount of time, which is never long enough anyway, as the issues listed on the common portage problems page - [2] - show.

Proposed solution

The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This allows package managers to trivially read the EAPI from the ebuild filename. It is also backwards compatible, because currently ebuilds are recognised by the .ebuild file extension and hence EAPI-suffixed ebuilds are simply ignored by the package managers.

Specification

Ebuild filename extension syntax: ebuild[-<EAPI>], where [] denotes an optional part, and <EAPI> is the EAPI of the ebuild.

Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps:

The above process should be only used to generate the metadata cache. Should the pre-source EAPI be unsupported the cache entry cannot be generated.

Ebuilds with unsupported EAPIs are masked.

QA tools should consider it an error for both EAPIs to be set explicitly to different values. Package managers may warn, but must use the post-source EAPI in such cases.

Examples:

Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing authors to provide backwards compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-version are equivalent, i.e. installing any of them has exactly the same effect on a given system.

Application

Note that the developers should only set the pre-source EAPI. The process described above is only necessary to avoid undefined behaviour in corner cases and to retain backwards compatibility.

QA tools may warn if the post-source EAPI is set at all, thus helping with the transition to the new format.

Other ideas

There were some other solutions proposed on the mailing list:

References

[1]GLEP 54, scm package version suffix (http://glep.gentoo.org/glep-0054.html)
[2]Common portage problems (http://www.gentoo.org/proj/en/portage/doc/common-problems.xml)

Copyright

This document has been placed in the public domain.