| 1 |
antarus 08/01/06 02:39:43 |
| 2 |
|
| 3 |
Modified: glep-0055.html glep-0055.txt |
| 4 |
Log: |
| 5 |
Editorially Bless glep 55 per changes I sent to peper |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.2 xml/htdocs/proj/en/glep/glep-0055.html |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0055.html?rev=1.2&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0055.html?rev=1.2&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0055.html?r1=1.1&r2=1.2 |
| 13 |
|
| 14 |
Index: glep-0055.html |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0055.html,v |
| 17 |
retrieving revision 1.1 |
| 18 |
retrieving revision 1.2 |
| 19 |
diff -u -r1.1 -r1.2 |
| 20 |
--- glep-0055.html 5 Jan 2008 02:42:59 -0000 1.1 |
| 21 |
+++ glep-0055.html 6 Jan 2008 02:39:42 -0000 1.2 |
| 22 |
@@ -1,11 +1,7 @@ |
| 23 |
<?xml version="1.0" encoding="utf-8" ?> |
| 24 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| 25 |
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
| 26 |
-<!-- |
| 27 |
-This HTML is auto-generated. DO NOT EDIT THIS FILE! If you are writing a new |
| 28 |
-PEP, see http://www.python.org/peps/pep-0001.html for instructions and links |
| 29 |
-to templates. DO NOT USE THIS HTML FILE AS YOUR TEMPLATE! |
| 30 |
---> |
| 31 |
+ |
| 32 |
<head> |
| 33 |
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
| 34 |
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" /> |
| 35 |
@@ -21,7 +17,7 @@ |
| 36 |
border="0" width="150" height="35" /></a></td> |
| 37 |
<td class="textlinks" align="left"> |
| 38 |
[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>] |
| 39 |
-[<b><a href="http://www.gentoo.org/peps">GLEP Index</a></b>] |
| 40 |
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>] |
| 41 |
[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0055.txt">GLEP Source</a></b>] |
| 42 |
</td></tr></table> |
| 43 |
<table class="rfc2822 docutils field-list" frame="void" rules="none"> |
| 44 |
@@ -82,10 +78,10 @@ |
| 45 |
EAPI the package manager needs to source the ebuild, which itself needs the EAPI |
| 46 |
in the first place. Otherwise it imposes a serious limitation, namely every ebuild, |
| 47 |
using any of the future EAPIs, will have to be source'able by old package |
| 48 |
-managers and hence there is no way to:</p> |
| 49 |
+managers and hence there is no way to do any of the following:</p> |
| 50 |
<blockquote> |
| 51 |
<ul class="simple"> |
| 52 |
-<li>Change behaviour of inherit in any way (for example, to extend or change |
| 53 |
+<li>Change the behaviour of inherit in any way (for example, to extend or change |
| 54 |
eclass functionality).</li> |
| 55 |
<li>Add new global scope functions in any sane way.</li> |
| 56 |
<li>Extend versioning rules in an EAPI - for example, addition of the scm |
| 57 |
@@ -107,7 +103,7 @@ |
| 58 |
<h1><a class="toc-backref" href="#id6" id="proposed-solution" name="proposed-solution">Proposed solution</a></h1> |
| 59 |
<p>The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This |
| 60 |
allows package managers to trivially read the EAPI from the ebuild filename. It |
| 61 |
-is also backward compatible, because currently ebuilds are recognised by the |
| 62 |
+is also backwards compatible, because currently ebuilds are recognised by the |
| 63 |
<tt class="docutils literal"><span class="pre">.ebuild</span></tt> file extension and hence EAPI-suffixed ebuilds are simply ignored by |
| 64 |
the package managers.</p> |
| 65 |
</div> |
| 66 |
@@ -137,7 +133,7 @@ |
| 67 |
<ul> |
| 68 |
<li><dl class="first docutils"> |
| 69 |
<dt><tt class="docutils literal"><span class="pre">pkg-1.ebuild</span></tt>, no EAPI set inside the ebuild</dt> |
| 70 |
-<dd><p class="first last">pre-source EAPI defaults 0, post-source EAPI defaults to pre-source EAPI. |
| 71 |
+<dd><p class="first last">pre-source EAPI defaults to 0, post-source EAPI defaults to pre-source EAPI. |
| 72 |
EAPI 0 is used.</p> |
| 73 |
</dd> |
| 74 |
</dl> |
| 75 |
@@ -167,7 +163,7 @@ |
| 76 |
<li><dl class="first docutils"> |
| 77 |
<dt><tt class="docutils literal"><span class="pre">pkg-5.ebuild-2</span></tt>, no EAPI set inside the ebuild, package manager not supporting EAPI 2</dt> |
| 78 |
<dd><p class="first last">pre-source EAPI is 2, post-source EAPI is never checked. |
| 79 |
-ebuild masked because of the unsupported pre-source EAPI.</p> |
| 80 |
+ebuild is masked because of the unsupported pre-source EAPI.</p> |
| 81 |
</dd> |
| 82 |
</dl> |
| 83 |
</li> |
| 84 |
@@ -176,7 +172,7 @@ |
| 85 |
<dd><p class="first last">pre-source EAPI defaults to 0, post-source EAPI is 2 (assuming the |
| 86 |
package manager didn't die when sourcing the ebuild thinking that EAPI 0 |
| 87 |
is used). |
| 88 |
-ebuild masked because of the unsupported post-source EAPI.</p> |
| 89 |
+ebuild is masked because of the unsupported post-source EAPI.</p> |
| 90 |
</dd> |
| 91 |
</dl> |
| 92 |
</li> |
| 93 |
@@ -184,11 +180,11 @@ |
| 94 |
</blockquote> |
| 95 |
<p>Note that it is still not permitted to have more than one ebuild with equal |
| 96 |
category, package name, and version. Although it would have the advantage of |
| 97 |
-allowing to provide backward compatible ebuilds, it would introduce problems |
| 98 |
-too. The first is the requirement to have strict EAPI ordering, the second is |
| 99 |
-ensuring that all the ebuilds for a single category/package-version are |
| 100 |
-equivalent, i.e. installing any of them has exactly the same effect to the |
| 101 |
-system.</p> |
| 102 |
+allowing authors to provide backwards compatible ebuilds, it would introduce |
| 103 |
+problems too. The first is the requirement to have strict EAPI ordering, the |
| 104 |
+second is ensuring that all the ebuilds for a single category/package-version |
| 105 |
+are equivalent, i.e. installing any of them has exactly the same effect on a |
| 106 |
+given system.</p> |
| 107 |
</div> |
| 108 |
<div class="section"> |
| 109 |
<h1><a class="toc-backref" href="#id8" id="application" name="application">Application</a></h1> |
| 110 |
@@ -208,8 +204,8 @@ |
| 111 |
<dd><ul class="first last simple"> |
| 112 |
<li>Doesn't meet the backward compatibility requirement.</li> |
| 113 |
<li>Isn't forward compatible either.</li> |
| 114 |
-<li>Could be confusing as ebuilds, and not without a reason, are |
| 115 |
-considered bash scripts and this would impose additional restrictions.</li> |
| 116 |
+<li>Could be confusing as ebuilds are considered bash scripts and this |
| 117 |
+would impose additional restrictions on the ebuild format.</li> |
| 118 |
</ul> |
| 119 |
</dd> |
| 120 |
</dl> |
| 121 |
@@ -266,7 +262,7 @@ |
| 122 |
<div class="footer"> |
| 123 |
<hr class="footer" /> |
| 124 |
<a class="reference" href="glep-0055.txt">View document source</a>. |
| 125 |
-Generated on: 2008-01-05 02:38 UTC. |
| 126 |
+Generated on: 2008-01-06 02:39 UTC. |
| 127 |
Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. |
| 128 |
|
| 129 |
</div> |
| 130 |
|
| 131 |
|
| 132 |
|
| 133 |
1.2 xml/htdocs/proj/en/glep/glep-0055.txt |
| 134 |
|
| 135 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0055.txt?rev=1.2&view=markup |
| 136 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0055.txt?rev=1.2&content-type=text/plain |
| 137 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0055.txt?r1=1.1&r2=1.2 |
| 138 |
|
| 139 |
Index: glep-0055.txt |
| 140 |
=================================================================== |
| 141 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0055.txt,v |
| 142 |
retrieving revision 1.1 |
| 143 |
retrieving revision 1.2 |
| 144 |
diff -u -r1.1 -r1.2 |
| 145 |
--- glep-0055.txt 5 Jan 2008 02:36:35 -0000 1.1 |
| 146 |
+++ glep-0055.txt 6 Jan 2008 02:39:42 -0000 1.2 |
| 147 |
@@ -1,7 +1,7 @@ |
| 148 |
GLEP: 55 |
| 149 |
Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) |
| 150 |
-Version: $Revision: 1.1 $ |
| 151 |
-Last-Modified: $Date: 2008/01/05 02:36:35 $ |
| 152 |
+Version: $Revision: 1.2 $ |
| 153 |
+Last-Modified: $Date: 2008/01/06 02:39:42 $ |
| 154 |
Author: Piotr Jaroszyński <peper@g.o> |
| 155 |
Status: Draft |
| 156 |
Type: Standards Track |
| 157 |
@@ -28,9 +28,9 @@ |
| 158 |
EAPI the package manager needs to source the ebuild, which itself needs the EAPI |
| 159 |
in the first place. Otherwise it imposes a serious limitation, namely every ebuild, |
| 160 |
using any of the future EAPIs, will have to be source'able by old package |
| 161 |
-managers and hence there is no way to: |
| 162 |
+managers and hence there is no way to do any of the following: |
| 163 |
|
| 164 |
- * Change behaviour of inherit in any way (for example, to extend or change |
| 165 |
+ * Change the behaviour of inherit in any way (for example, to extend or change |
| 166 |
eclass functionality). |
| 167 |
|
| 168 |
* Add new global scope functions in any sane way. |
| 169 |
@@ -55,7 +55,7 @@ |
| 170 |
|
| 171 |
The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This |
| 172 |
allows package managers to trivially read the EAPI from the ebuild filename. It |
| 173 |
-is also backward compatible, because currently ebuilds are recognised by the |
| 174 |
+is also backwards compatible, because currently ebuilds are recognised by the |
| 175 |
``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by |
| 176 |
the package managers. |
| 177 |
|
| 178 |
@@ -87,7 +87,7 @@ |
| 179 |
Examples: |
| 180 |
|
| 181 |
* ``pkg-1.ebuild``, no EAPI set inside the ebuild |
| 182 |
- pre-source EAPI defaults 0, post-source EAPI defaults to pre-source EAPI. |
| 183 |
+ pre-source EAPI defaults to 0, post-source EAPI defaults to pre-source EAPI. |
| 184 |
EAPI 0 is used. |
| 185 |
|
| 186 |
* ``pkg-2.ebuild-1``, no EAPI set inside the ebuild |
| 187 |
@@ -105,21 +105,21 @@ |
| 188 |
|
| 189 |
* ``pkg-5.ebuild-2``, no EAPI set inside the ebuild, package manager not supporting EAPI 2 |
| 190 |
pre-source EAPI is 2, post-source EAPI is never checked. |
| 191 |
- ebuild masked because of the unsupported pre-source EAPI. |
| 192 |
+ ebuild is masked because of the unsupported pre-source EAPI. |
| 193 |
|
| 194 |
* ``pkg-6.ebuild``, ``EAPI="2"``, package manager not supporting EAPI 2 |
| 195 |
pre-source EAPI defaults to 0, post-source EAPI is 2 (assuming the |
| 196 |
package manager didn't die when sourcing the ebuild thinking that EAPI 0 |
| 197 |
is used). |
| 198 |
- ebuild masked because of the unsupported post-source EAPI. |
| 199 |
+ ebuild is masked because of the unsupported post-source EAPI. |
| 200 |
|
| 201 |
Note that it is still not permitted to have more than one ebuild with equal |
| 202 |
category, package name, and version. Although it would have the advantage of |
| 203 |
-allowing to provide backward compatible ebuilds, it would introduce problems |
| 204 |
-too. The first is the requirement to have strict EAPI ordering, the second is |
| 205 |
-ensuring that all the ebuilds for a single category/package-version are |
| 206 |
-equivalent, i.e. installing any of them has exactly the same effect to the |
| 207 |
-system. |
| 208 |
+allowing authors to provide backwards compatible ebuilds, it would introduce |
| 209 |
+problems too. The first is the requirement to have strict EAPI ordering, the |
| 210 |
+second is ensuring that all the ebuilds for a single category/package-version |
| 211 |
+are equivalent, i.e. installing any of them has exactly the same effect on a |
| 212 |
+given system. |
| 213 |
|
| 214 |
Application |
| 215 |
=========== |
| 216 |
@@ -139,8 +139,8 @@ |
| 217 |
* Set the EAPI inside the ebuild in a way that makes it easy to fetch it |
| 218 |
* Doesn't meet the backward compatibility requirement. |
| 219 |
* Isn't forward compatible either. |
| 220 |
- * Could be confusing as ebuilds, and not without a reason, are |
| 221 |
- considered bash scripts and this would impose additional restrictions. |
| 222 |
+ * Could be confusing as ebuilds are considered bash scripts and this |
| 223 |
+ would impose additional restrictions on the ebuild format. |
| 224 |
|
| 225 |
* Do the above and change the ebuild extension to ``.ebuild-ng`` |
| 226 |
* Meets the backward compatibility requirement. |
| 227 |
|
| 228 |
|
| 229 |
|
| 230 |
-- |
| 231 |
gentoo-commits@g.o mailing list |
Archives