From: | "Michał Górny" <mgorny@g.o> | ||
---|---|---|---|

To: | gentoo-dev@l.g.o | ||

Cc: | antarus@g.o | ||

Subject: | Re: [gentoo-dev] RFD: EAPI specification in ebuilds |
||

Date: | Thu, 08 Mar 2012 12:04:58 | ||

Message-Id: | 20120308130620.75b45696@pomiocik.lan |
||

In Reply to: | Re: [gentoo-dev] RFD: EAPI specification in ebuilds by Alec Warner |

1 | On Wed, 7 Mar 2012 20:12:25 -0800 |

2 | Alec Warner <antarus@g.o> wrote: |

3 | |

4 | > On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller <ulm@g.o> |

5 | > wrote: |

6 | > > Hi all, |

7 | > > |

8 | > > The way how we currently specify the EAPI in ebuilds has some |

9 | > > problems. For example, there is no sane way to allow usage of |

10 | > > features of a new bash version in a new EAPI. So we are currently |

11 | > > stuck with bash 3.2. Also changes of global scope behaviour, like |

12 | > > addition of new global scope functions (similar to "inherit") are |

13 | > > not possible. |

14 | > > |

15 | > > These flaws are outlined in GLEP 55 [1]: |

16 | > > | In order to get the EAPI the package manager needs to source the |

17 | > > | ebuild, which itself needs the EAPI in the first place. Otherwise |

18 | > > it | imposes a serious limitation, namely every ebuild, using any |

19 | > > of the | future EAPIs, will have to be source'able by old package |

20 | > > managers | [...] |

21 | > > |

22 | > > The council has voted down GLEP 55 more than a year ago, but at the |

23 | > > same time requested that a solution for the mentioned issues should |

24 | > > be found. [2] However, there was no progress since then. |

25 | > > |

26 | > > The issue arose again in bug 402167 [3] where several solutions have |

27 | > > been discussed. Below, I try to summarise the possible options |

28 | > > resulting from that discussion. |

29 | > > |

30 | > > |

31 | > > *** Proposal 1: "Parse the EAPI assignment statement" *** |

32 | > > |

33 | > > This first proposal would require that the syntax of the EAPI |

34 | > > assignment statement in ebuilds matches a well defined regular |

35 | > > expression. A scan of the Portage tree shows that the statement only |

36 | > > occurs in the following variations (using EAPI 4 as example): |

37 | > > |

38 | > > EAPI=4 |

39 | > > EAPI="4" |

40 | > > EAPI='4' |

41 | > > |

42 | > > Sometimes this is followed by whitespace or a comment (starting with |

43 | > > a # sign). Also, with very few exceptions the EAPI assignment occurs |

44 | > > within the first few lines of the ebuild. For the vast majority of |

45 | > > ebuilds it is in line 5. |

46 | > > |

47 | > > Written in a more formal way, appropriate for a specification: |

48 | > > - Ebuilds must contain at most one EAPI assignment statement. |

49 | > > - It must occur within the first N lines of the ebuild (N=10 and |

50 | > > N=30 have been suggested). |

51 | > > - The statement must match the following regular expression |

52 | > > (extended regexp syntax): |

53 | > > ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ |

54 | > > |

55 | > > Note: The first and the third point are already fulfilled by all |

56 | > > ebuilds in the Portage tree. The second point will require very few |

57 | > > ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). |

58 | > > |

59 | > > The package manager would determine the EAPI by parsing the |

60 | > > assignment with above regular expression. A sanity check would be |

61 | > > added. Citing Zac Medico in [3]: "The fact that we can compare the |

62 | > > probed EAPI to the actual EAPI variable after the ebuild is sourced |

63 | > > seems like a perfect sanity check. We could easily detect |

64 | > > inconsistencies and flag such ebuilds as invalid, providing a |

65 | > > reliable feedback mechanism to ebuild developers." |

66 | > > |

67 | > > This proposal comes in two variants: |

68 | > > 1a) The change is applied retroactively for all EAPIs. |

69 | > > 1b) It is only applied for EAPI 5 and later (which means that the |

70 | > > result of the EAPI parsing would be discarded for earlier EAPIs). |

71 | > |

72 | > I don't like this idea because the sane way should be easy and |

73 | > straightforward. Mixing a constant declaration with bash assignment |

74 | > just confuses users who think the assignment is full bash when in |

75 | > fact it is not. |

76 | > |

77 | > EAPI=$(somefunc) |

78 | > EAPI=${SOMEVAR%%-*} |

79 | > and so forth all don't meet the regex (and would be flagged invalid.) |

80 | > However a naive author might think they work. |

81 | |

82 | And they all should be invalid due to our policies. The most important |

83 | ebuild variables like EAPI should be readable on sight, without having |

84 | to lookup random variables, functions etc. |

85 | |

86 | -- |

87 | Best regards, |

88 | Michał Górny |

File name | MIME type |
---|---|

signature.asc | application/pgp-signature |

All times displayed are in UTC (GMT+0).

Contents reflect the opinion of the author, not the Gentoo project or the Gentoo Foundation.

Gentoo is a trademark of the Gentoo Foundation, Inc. The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-4.0 license. The Gentoo Name and Logo Usage Guidelines apply.