[gentoo-dev] Re: Re: Re: The fallacies of GLEP55

[Steven J Long]

Ciaran McCreesh wrote:

> On Fri, 15 May 2009 21:06:13 +0100
> Steven J Long wrote:
>> > Before an ebuild has had its metadata generated, its EAPI is
>> > unknown. At this point, the package manager assumes EAPI 0.
>> >
>> With the format restriction, that everyone last year seemed happy
>> with, apart from the few pushing GLEP-55, this isn't an issue.
>
> The format restriction hasn't been agreed upon,
By you. (oh, and your gang.) You're right though, it hasn't been spammed to
the list on more occasions than anyone cares to remember, nor has it been
pushed up to the Council to vote on, when someone can't convince the rest
of the developer community. It just works.

> and doesn't solve the whole problem anyway.

Only we're not allowed to hear what problem you _think_ exists. You just
resort to the Emperor's New Clothes defence. ("I can't explain it, as the
fact you don't agree with me, clearly means you're far too stupid to
explain it to.")

Sorry but those clothes look like rags to me.

Shiny you say? Explain it then, as they /still/ look like rags.

Or stop wasting everybody's time. Pick one.

>> If you have a use-case that actually requires more in a version
>> specifier for upstream software, please present it and explain how it
>> cannot be represented with the above.
>
> Go and look at all the ebuilds using MY_PV style hacks. Group these
> into "necessary because upstream are being silly" and "we're only doing
> this because of some utterly arbitrary rules imposed in the early days
> of Gentoo". Most are in the second camp.
>
Please elucidate the use-case, and how the versions cannot be represented
within Gentoo, or within the expanded def'n[2] as you were asked to do.

If you're concerned about stupid BASH, perhaps you could direct your energy
towards better BASH scripting, and not relying on an eclass to do what #bash
beginners learn in their first two weeks. Learning the craft is part of the
process. I realise openly sharing knowledge makes it harder for you to
hoard it. Deal with it, or don't work in Free software.

As for "utterly arbitrary" some of the syntax you've proposed is exactly
that. Even worse, it's completely cack-handed. That'd be fine if you didn't
also insist that everything you dream up is perfectly worked-out and
thought-through from the beginning[1]. The combination is quite dangerous,
and were this a professional situation you'd have been out on your ear a
long time ago. Not storming back after being 'fired' and emailing the whole
company with your rants for the next 3 years.

>> In passing, I must express bewildered amusement at the idea of a
>> format with an unlimited amount of extensions.
>
> Not what's being proposed. We're proposing giving each format its own
> file extension.
>
No, you're trying to hijack .ebuild. Even cat-foo/blah-version--EAPI.ebuild
would be better than this nonsense.

It'd *still* be a bad idea for all the reasons lavajoe (iirc) outlined way
back when. I suggest you re-read his post from a long time ago.

If you want to do a radically new format, go ahead; no-one's stopping you or
holding your work back in any way. The same cannot be said for your
continued antics.

Oh yeah, .exheres hasn't quite got the same cachet as .ebuild. No
satisfaction in it, unlike getting Gentoo to 'submit'.

I still haven't seen a version that cannot be handled within the Gentoo
schema (and I note you were remarkably silent on suggestions that were put
to you[2], as you always are if they didn't come from paludis.) If you're
arguing no human input should be required, I think you have a
misunderstanding of the user-base.

Some of us prefer to know that a human has both tried the ebuild out, and
gone through repoman. And that that person takes pride in their name on the
commit, and stands by the principle of "you broke it, you fix it."

It's called a distribution, not "ciara's collection of stuff scraped from a
webservice."

[1] 'If it is unwise to trust other people's claims for "one true way", it's
even more foolish to believe them about your own designs.'
http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2879078
[You seem not to have read this site _at all_. Correct that before posting
again.]

[2] "Let's just use a prefix instead of a suffix to indicate vcs, keep
branch and upstream for dep specification, not filename, to allow
inter-repo dependency for overlays for the few cases where it's actually
needed, and add debian-style epochs to guarantee future expansion."

--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)