* [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
@ 2009-02-23 13:57 99% ` Ciaran McCreesh
0 siblings, 0 replies; 1+ results
From: Ciaran McCreesh @ 2009-02-23 13:57 UTC (permalink / raw
To: Luca Barbato; +Cc: gentoo-council, gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Let's try to start with a common workflow for the user:
> - an user with an ancient version of portage syncs
> - it requires a package
> - it looks at the cache ($portdir/metadata/cache/)
> - picks the best entry from the ones showing an eapi it understands
> - keeps going.
>
> Apparently we do not have any issue...
...assuming the metadata cache is valid. That isn't always the case.
> 2- The user will get unpredictable behavior, but portage tell you
> when upgrading is needed...
Not if the version you'd need to do metadata generation is ~arch it
doesn't.
> 3- you'd have to disable them
Yes, tell everyone to disable all the overlays that make use of a few
features only in ~arch package managers... That'll work...
> In this case we have a problem if the source step is a single one,
> portage won't know in advance how to behave.
>
> So the first step has to be split in two:
> - first portage discovers which is the eapi version
...which it can't do, because it doesn't know the EAPI.
> The problem is that right now sourcing is done by having an
> instructed bash. So the simplest way to get the first step done is
> parsing the ebuild file with something different like file(1) and
> then instruct bash and do the parsing.
file(1) can't parse ebuilds. Only an ebuild implementation can parse
ebuilds, and only if it already knows the EAPI.
> What is proposed in glep-55 seems to aim to solve both issues at the
> same time (it isn't stated) by switching file extension every time
> the eapi is changed. This is slightly against the principle of the
> least surprise and apparently is disliked by enough people to lead
> the situation to be discussed in the council.
There's no surprise at all. It's extremely clear.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <1234257125.18160.2016.camel@localhost>
[not found] ` <1234450419.20950.2.camel@localhost>
[not found] ` <20090212160045.GB3642@comet>
[not found] ` <20090212161644.GD3642@comet>
[not found] ` <20090212162103.256b003f@snowcone>
[not found] ` <20090212171055.GA3652@comet>
[not found] ` <20090212172109.778fb268@snowcone>
[not found] ` <20090212173743.GD3652@comet>
[not found] ` <20090212180350.0d9a9df5@snowcone>
[not found] ` <1235037961.13198.779.camel@localhost>
[not found] ` <20090219125124.33eaa66c@snowcone>
[not found] ` <1235077892.13198.1923.camel@localhost>
[not found] ` <20090222171658.278ae167@halo.dirtyepic.sk.ca>
[not found] ` <49A1E1CB.1000806@gentoo.org>
[not found] ` <20090222234800.29d64b8d@snowcone>
2009-02-23 2:15 ` [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Luca Barbato
2009-02-23 13:57 99% ` [gentoo-dev] " Ciaran McCreesh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox