Gentoo Archives: gentoo-council

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: Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Date: Mon, 23 Feb 2009 14:46:28
Message-Id: 49A2B6C0.1070900@gentoo.org
In Reply to: Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) by Ciaran McCreesh
1 Ciaran McCreesh wrote:
2 > On Mon, 23 Feb 2009 03:15:03 +0100
3 > Luca Barbato <lu_zero@g.o> wrote:
4 >> Let's try to start with a common workflow for the user:
5 >> - an user with an ancient version of portage syncs
6 >> - it requires a package
7 >> - it looks at the cache ($portdir/metadata/cache/)
8 >> - picks the best entry from the ones showing an eapi it understands
9 >> - keeps going.
10 >>
11 >> Apparently we do not have any issue...
12 >
13 > ...assuming the metadata cache is valid. That isn't always the case.
14
15 When it isn't?
16
17 >> 2- The user will get unpredictable behavior, but portage tell you
18 >> when upgrading is needed...
19 >
20 > Not if the version you'd need to do metadata generation is ~arch it
21 > doesn't.
22
23 ...
24
25 >> 3- you'd have to disable them
26 >
27 > Yes, tell everyone to disable all the overlays that make use of a few
28 > features only in ~arch package managers... That'll work...
29
30 disable overlays to UPGRADE to the new portage. Not rocket science...
31
32 >> In this case we have a problem if the source step is a single one,
33 >> portage won't know in advance how to behave.
34 >>
35 >> So the first step has to be split in two:
36 >> - first portage discovers which is the eapi version
37 >
38 > ...which it can't do, because it doesn't know the EAPI.
39
40 If you are generating the cache you must have a way to know it...
41
42 >> The problem is that right now sourcing is done by having an
43 >> instructed bash. So the simplest way to get the first step done is
44 >> parsing the ebuild file with something different like file(1) and
45 >> then instruct bash and do the parsing.
46 >
47 > file(1) can't parse ebuilds.
48
49 file parses quite well avi and mov, ebuild will be anytime more complex
50 than that right?
51
52 Anyway it isn't a problem since the version of portage doing the work is
53 supposed to be up to date, if isn't it will be updated first using the
54 normal user workflow that has already been covered by the cache.
55
56 > Only an ebuild implementation can parse
57 > ebuilds, and only if it already knows the EAPI.
58
59 That is always the case since you are adding an ebuild and you are
60 supposed to have an up to date portage in order to do that.
61
62 >> What is proposed in glep-55 seems to aim to solve both issues at the
63 >> same time (it isn't stated) by switching file extension every time
64 >> the eapi is changed. This is slightly against the principle of the
65 >> least surprise and apparently is disliked by enough people to lead
66 >> the situation to be discussed in the council.
67 >
68 > There's no surprise at all. It's extremely clear.
69
70 Not that much.
71
72 lu
73
74 --
75
76 Luca Barbato
77 Gentoo Council Member
78 Gentoo/linux Gentoo/PPC
79 http://dev.gentoo.org/~lu_zero

Replies

Subject Author
Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>