Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Luca Barbato <lu_zero@g.o>
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:59:13
Message-Id: 20090223145902.0207a965@snowcone
In Reply to: Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) by Luca Barbato
1 On Mon, 23 Feb 2009 15:46:24 +0100
2 Luca Barbato <lu_zero@g.o> wrote:
3 > >> Apparently we do not have any issue...
4 > >
5 > > ...assuming the metadata cache is valid. That isn't always the case.
6 >
7 > When it isn't?
8
9 Every now and again (probably after someone changes eutils...), rsync
10 mirrors end up shipping a load of stale metadata for parts of the tree.
11 Portage users probably don't notice, since it just causes a slowdown.
12
13 > disable overlays to UPGRADE to the new portage. Not rocket science...
14
15 No no. You're forcing people to switch to ~arch to be able to use
16 overlays.
17
18 > >> In this case we have a problem if the source step is a single one,
19 > >> portage won't know in advance how to behave.
20 > >>
21 > >> So the first step has to be split in two:
22 > >> - first portage discovers which is the eapi version
23 > >
24 > > ...which it can't do, because it doesn't know the EAPI.
25 >
26 > If you are generating the cache you must have a way to know it...
27
28 No, we don't. That's the entire frickin' point of GLEP 55, and one
29 that you would do well to understand fully before commenting further.
30 The way we generate metadata now is massively horrible, and only works
31 because there aren't any serious global scope differences between
32 EAPIs. We can't make any global scope changes to future EAPIs because
33 it breaks current metadata generation. Right now it's safe to pretend
34 EAPI 0 until the real EAPI is worked out, but that won't hold in the
35 future -- as soon as global scope changes come along, there's no safe
36 EAPI that can be assumed, even if we didn't have to worry about
37 breaking existing package managers.
38
39 > >> The problem is that right now sourcing is done by having an
40 > >> instructed bash. So the simplest way to get the first step done is
41 > >> parsing the ebuild file with something different like file(1) and
42 > >> then instruct bash and do the parsing.
43 > >
44 > > file(1) can't parse ebuilds.
45 >
46 > file parses quite well avi and mov, ebuild will be anytime more
47 > complex than that right?
48
49 It's already *way* more complicated than that. Extracting metadata
50 requires a full bash 3 implementation along with a considerable amount
51 of supporting code.
52
53 > Anyway it isn't a problem since the version of portage doing the work
54 > is supposed to be up to date, if isn't it will be updated first using
55 > the normal user workflow that has already been covered by the cache.
56
57 Most users don't run ~arch, and do use overlays. So no, this will affect
58 normal user workflow.
59
60 > > Only an ebuild implementation can parse
61 > > ebuilds, and only if it already knows the EAPI.
62 >
63 > That is always the case since you are adding an ebuild and you are
64 > supposed to have an up to date portage in order to do that.
65
66 Again, you're not getting it. Doesn't matter how up to date your
67 package manager is. You can't find out the EAPI unless you already know
68 the EAPI.
69
70 > >> What is proposed in glep-55 seems to aim to solve both issues at
71 > >> the same time (it isn't stated) by switching file extension every
72 > >> time the eapi is changed. This is slightly against the principle
73 > >> of the least surprise and apparently is disliked by enough people
74 > >> to lead the situation to be discussed in the council.
75 > >
76 > > There's no surprise at all. It's extremely clear.
77 >
78 > Not that much.
79
80 How is '.ebuild-3' being used to specify version 3 of the ebuild format
81 in the least bit surprising?
82
83 --
84 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature