Duncan wrote: > Thilo Bangert <bang...@gentoo.org> posted > 200905311126.00274.bang...@gentoo.org, excerpted below, on Sun, 31 May > 2009 11:25:56 +0200: > >> the thing is though, nothing constructive is being said. people are >> going in circles. ciaran and co are pushing glep55 for reasons which >> they have stated gazillion of times and nothing new is coming about. >> >> other people dislike glep55 for various reasons, but they clearly fail >> at proposing a (better) alternative (a competing GLEP). > >> please, please DO write a competing GLEP if you dislike GLEP55. it's >> late, but you might just make it... > > And this is why GLEP55 is likely ultimately going to be approved, despite > all the arguing. At the end of the day, we'll need /some/ solution to > the general problem
First we have to agree that there /is/ a problem. "Allowing -rc1 as opposed to _rc1" is "the big one" apparently. No-one answered when I asked why an internal format specification needs to allow this, or indeed more variants on versions. (IME it's *better* to restrict it to one variant.) Again, debian-style epochs (simply a numeric integer followed by : before the usual ([0-9]+) at the start of a version) allow us this flexibility, but as I explained before, this use-case doesn't merit it. They're used in Debian when upstream changes to a non-compatible (eg overlapping) new version sequence. Whether that's needed in Gentoo, or whether they could be used in a more interesting manner is another discussion, which I for one would find a lot more interesting than debating someone's unwillingness to take 'no' for an answer. >, and the proponents of GLEP55 have troubled > themselves to write a GLEP outlining their solution To a non-existent problem. > in some depth as well > as argue for it over a period of /years/, while the opponents have... > troubled themselves enough to argue it for years. > Well I'm actually a bit bemused that we are still discussing it. It's a rank amateur solution to a non-issue, that I thought was dismissed by consensus a year ago. A minority not accepting the majority viewpoint doesn't change that that *is* what happened. EAPI doesn't belong in filename the same way ACCEPT_KEYWORDS doesn't. Or is that the next step, so that the mangler knows visibility from filename and doesn't have to open the cache file? What next, DEPEND too? Getting into a nonsensical debate about PN being metadata seems to be the level of the argument, so forgive me for not being very impressed. (It's externally derived and in fact the whole point of the product; unless someone is proposing losing PN and PV from filename, can we *please* dismiss that argument as the irrelevance which it is?) > A team can have the best rhetoric in the world, but if they don't > actually show up and field a team on game day, they lose by default. > Fortunately or unfortunately, that looks to be where this is headed. > FEATURES=parse-eapi-ebuild-head shows one possible implementation. Personally I favour restricting the EAPI='blah' line (which imo should simply be single-quoted to avoid escaping issues, but whatever: it's easy enough to lex in C, so I fail to see the issue lexing it anywhere else) to before the inherit line _in_ _the_ _spec_ since no-one has given any reason why we should want to do anything else, and afaik repoman will warn about it anyhow. Could *you* explain to us, why that restriction is such a bad thing? In summary: the existing design, including harring's EAPI, suffices for all the 'problems' raised. The most we need to do is specify that the mangler is allowed to extract the EAPI without sourcing, the restrictions that enable this, and that global-scope EAPI functions (including a later BASH version) are consequently allowed. In the meantime, while we've been discussing this for God knows how long, we still don't have LDEPENDs, nor do we have elibs which harring envisaged alongside eclasses and EAPI in the first place. "Broken process" afaic. Oh btw, -scm [sic] suffix doesn't add ANYTHING to the existing cvs. prefix that's been available in portage for at least 3 years; it's a binary datum, either there or not. "Innovation" is not what I'd call all this. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
