Gentoo Archives: gentoo-dev

From: Luca Barbato <lu_zero@g.o>
To: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Cc: gentoo-council@l.g.o, gentoo-dev@l.g.o
Subject: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Date: Mon, 23 Feb 2009 02:15:09
1 Ciaran McCreesh wrote:
2 > Because your proposal addresses none of the underlying problems which
3 > GLEP 55 was created to solve.
5 As said long ago the glep doesn't tell enough:
7 "The current way of specifying the EAPI in ebuilds is flawed. In order
8 to get the EAPI the package manager needs to source the ebuild, which
9 itself needs the EAPI in the first place. Otherwise it imposes a serious
10 limitation, namely every ebuild, using any of the future EAPIs, will
11 have to be source'able by old package managers and hence there is no way
12 to do any of the following:
14 * Change the behaviour of inherit in any way (for example, to
15 extend or change eclass functionality).
16 * Add new global scope functions in any sane way.
17 * Extend versioning rules in an EAPI - for example, addition of
18 the scm suffix - GLEP54"
20 Let's try to start with a common workflow for the user:
21 - an user with an ancient version of portage syncs
22 - it requires a package
23 - it looks at the cache ($portdir/metadata/cache/)
24 - picks the best entry from the ones showing an eapi it understands
25 - keeps going.
27 Apparently we do not have any issue...
29 Now problems:
30 1- the cache could get a non compatible change
31 2- the user triggers a metadata cache regeneration
32 -> the ebuild is sourced -> portage could fail or do something
33 unpredictable
34 3- overlays do not provide metadata cache
35 4- A package manager different from portage do not use the provided cache.
37 Solutions:
38 1- move the incompatible cache out of ancient portage scope (like in a
39 separate directory)
40 2- The user will get unpredictable behavior, but portage tell you when
41 upgrading is needed...
42 3- you'd have to disable them
43 4- unsupported.
45 Apparently for this side we don't have much to do if we get a valid cache.
47 Ebuilds have to be added to portage so here the workflow for the developer:
49 - new ebuild is sourced
50 - cache is generated
51 - manifest is built
53 In this case we have a problem if the source step is a single one,
54 portage won't know in advance how to behave.
56 So the first step has to be split in two:
57 - first portage discovers which is the eapi version
58 - then behave as defined by the eapi
60 The problem is that right now sourcing is done by having an instructed
61 bash. So the simplest way to get the first step done is parsing the
62 ebuild file with something different like file(1) and then instruct bash
63 and do the parsing.
65 This will solve the issue for the developer.
67 What is proposed in glep-55 seems to aim to solve both issues at the
68 same time (it isn't stated) by switching file extension every time the
69 eapi is changed. This is slightly against the principle of the least
70 surprise and apparently is disliked by enough people to lead the
71 situation to be discussed in the council.
73 The fact the glep itself is too much terse doesn't help acknowledging
74 the problems it aims to solve and the fact it fails to state actual
75 issues that may need a solution doesn't make it worth the effort and
76 disruption it would lead.
78 lu
80 --
82 Luca Barbato
83 Gentoo Council Member
84 Gentoo/linux Gentoo/PPC