[gentoo-dev] Re: The fallacies of GLEP55

[Mark Bateman]

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:

>
> On Sat, 16 May 2009 21:58:10 +0000 (UTC)
> Mark Bateman <couldbe <at> soon.com> wrote:
> > "The current way of specifying the EAPI in ebuilds is flawed"
> > That is not defining the problem, that is an opening statement.
>
> That is the problem.
No, that is a summary of the problem. Not once has the actual problem been 
described or documented. It has been requested multiple times by multiple 
people and yet a description detailing the problem has yet to materialise.
Repeated use of *problem* doesn't suddenly expand on the definition of the word 
*problem* to encompass details needed in a technical proposal within a GLEP.
If you do not understand the problems associated with determining the EAPI of 
an ebuild before sourcing it, please stop championing this GLEP until someone 
does provide a complete breakdown of the process.

Until such information is provided continued discussion of this GLEP is not 
going to progress since words like *obviously* are substituted for actual 
facts, a substitution which does not provide anything new to this discussion
 
> > "In order to get the EAPI the package manager needs to source the
> > ebuild, which itself needs the EAPI in the first place."
> > It then describes "a" mechanism utilising an ebuild
> > (source /usr/portage...) to obtain the EAPI from within the ebuild
> > (EAPI=...). Using this method the entire content of GLEP55 is
> > accurate.
> >
> > However, this is not the only method to determine the EAPI of an
> > ebuild that exists and as such the viability of GLEP55 as the best
> > solution is brought into question
>
> Yes, it is the only method.
No it is the only method you are willing to accept, there is a big difference. 
Many people have mentioned in passing other means of determining the EAPI of 
an ebuild pre-sourcing (thus allowing the PM to source the correct eclass
or flag up warnings...) YET they have just been shot down with no 
actual technical reason, except "they do not involve coding the EAPI 
into the filename". Please provide detailed technical description of 
the problem, as has been requested by a number of people, as well as 
providing details of why in-filename encoding of EAPI is technically 
as well as practically the best solution.



>
> > Where is it defined that the ebuild must be sourced 1st?
> > Why does the ebuild have to be sourced 1st?
>
> Such things are obviously true to anyone with a basic understanding of
> the domain.
So you are unable to actually reference any credible source of information to 
back up your claims then.

>
> > GLEP55 explicitly states that the EAPI to be recorded in the file
> > extension, while, as this thread has shown, a number of methods can
> > be used to source the EAPI version of the ebuild *without* the need
> > of actually source'ing the ebuild (grep, sed, metacache) all of which
> > are viable solutions to the problem, the problem that is so obvious
> > it doesn't actually have to be defined
>
> Except that that isn't true. With the current rules, an ebuild has to
> be sourced to get EAPI. And you can't just say "use the metadata
> cache", since the package manager has to know how to generate the
> metadata cache in the first place.
>
> Please make sure you're familiar with the basics of how metadata works
> before commenting any further.
>
What has my understanding or lack of understanding of "metadata" have to do 
with my statement that other means exist to determine the EAPI of an ebuild 
before sourcing said ebuild? This is meant to be a discussion about "The 
fallacies of GLEP55" 

Refusal to accept any other possible solution as well as refusal to discuss any 
other solution to the problem, all wrapped up in an awe of supremacy on the 
matter (without ONCE providing details) is not beneficial to Gentoo in finding 
the best solution.

Simple fact is there are many methods available to determine the EAPI of an 
ebuild without having to encode it in the filename (or its extension).
In fact you yourself have mentioned that eclasses change the EAPI
http://article.gmane.org/gmane.linux.gentoo.devel/61255
"But eclasses have tried changing it. This is something people have
done, not some hypothetical." 
So the need to have it actually encoded in the filename is not needed, since 
other method's of actually setting the EAPI exist and work.

Blindly dismissing a solution without actually providing any technical 
information of the problem AS well as why a *proposed* solution isn't the best 
is of no benefit to solving the problem

For instance SheBangs are very useful

FILE:test1.py
#!/usr/bin/python2.5
#-*- coding: utf-8 -*-
def bin(number,count):
    return '0b'+"".join([str((number >> y) & 1) for y in range(count-1,-1,-1)])

print 'hello world ',bin(170,8)

FILE:test2.py
#!/usr/bin/python2.6
#-*- coding: utf-8 -*-
print('hello world',bin(170))


executing ./test1  and ./test2 both work WHILE "python2.5 test2.py" fails on 
NameError.
There is no need for the python version to be encoded into the filename (like 
*.py-2.6) and yet it still works.