Re: [gentoo-dev] The fallacies of GLEP55

[Nick Fortino <nfortino@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 22:39:46 +0530
> Arun Raghavan <ford_prefect@gentoo.org> wrote:
>  
>> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
>>    
>>>> Don't care. Let's fix the problems we have *now* using solutions
>>>> that we can agree upon, rather than try to foist solutions that a
>>>> reasonably large population of developers *don't* like (even after
>>>> extended debate) to solve problems that don't exist yet.
>>>>        
>>> No, let's fix it so we don't have to do the whole thing again in
>>> another year or two.
>>>      
>> I see nothing about the current problem that merits the fooling around
>> with the ebuild extension. I've listened to and considered all the
>> arguments that have been made, and I still stand by my opinion that it
>> an unclean solution (meaning, we don't need to rehash those arguments
>> again here).
>>    
>
> You have yet to provide an alternative for fixing the arbitrary and
> pointless version format restrictions that are currently in place.
>
>
>  

It seems to me that putting the EAPI in a fixed place in the file has
nearly identical freedom as specifying the EAPI in the file name, and
therefore the argument is more philosophical than based upon features.

To be concrete, consider two proposals,
1. For an ebuild wishing to be sourced with EAPI != 0, line 4 shall be
blank and line 5 shall contain the string EAPI="arg", where arg is the
desired EAPI.
2. An ebuild wishing to be sourced with EAPI != 0 shall have the
extension .ebuild-EAPIarg, where arg is the desired EAPI.

Throughout, these shall be referred to as ebuilds of type 1 and 2
respectively.

I claim for any format where the concept of line 4 and line 5 are well
defined and identical across EAPIs, and the EAPI string embeddable in
the file name, these two proposals allow identical expressive power.[1][2]

"Proof":
Given a set of ebuilds of type 1 transform to ebuilds of type 2 as
follows: for every ebuild ${A}.ebuild, look for a blank line 4 and
line 5 with EAPI="arg". If found, move the ebuild to
${A}.ebuild-EAPIarg, and remove lines 4 and 5. Otherwise, move the
file to ${A}.ebuild-EAPI0.

Given a set of ebuilds of type 2 transform to ebuilds of type 1 as
follows: for every ebuild ${A}.ebuild-EAPIarg, insert a blank line 4
and put the string EAPI="arg" on line 5. move the ebuild to
${A}.ebuild. For every ebuild ${A}.ebuild, insert a blank line 4, and
EAPI="0" on line 5.

Such a transformation is possible, given the restrictions on arg, as
well as ebuild format.

Given the further restriction that any algorithm using ebuilds must
behave identically with ebuilds of unspecified EAPI as with ebuilds
with specified EAPI="0" [3], it can easily be seen that the two
transformations are inverses of each other, and that every ebuild of
either type can be transformed. Thus, the above must be a one-to-one
and onto mapping between the two formats. The conclusion is any
algorithm which can be run on a set of ebuilds type 1 has a set of
ebuilds with type 2 and an appropriate algorithm for which identical
results will be produced, and vice versa [4].

Given the above, it should be clear that any argument which states
some future improvement to the ebuild format  will be impossible based
upon making the wrong choice between proposal 1 and proposal 2 must be
invalid, as they have the same expressive power. Note that allowable
algorithms for which the proof works includes caching and version
ordering as well as the simple execution of the ebuild.


Nick Fortino

[1] I further state, philosophically, any formats which have differing
(including non-existent) concepts of line 4 and line 5 should have
different extensions. Proposal 2 takes care of this automatically. For
any format, the desired EAPI should be specifiable within the file in
a manner uniquely determined by the extension of the file, so proposal
1 is also capable of achieving this freedom.

[2] The astute reader may notice that the concept of a blank line is
also needed, and that line 5 must be capable of encoding the desired
data in a way specified by only the extension. To avoid clutter, these
details are located here, but are in fact restrictions made on the
ebuild format.

[3] There are no algorithms I know of which violate this for EAPI="0",
and I would hope that there are no EAPI="0" ebuilds which are broken
by putting this specification explicitly in the file. Similarly, I
would hope that anything in proposal 2 with EAPI="0" which works with
the .ebuild extension works with the .ebuild-EAPI0 extension.
Note that one could dream up algorithms violating this (take the MD5
hash, do something based on this which affects the outcome). Doing
such a thing where the difference would be visible to the user would
be silly. It is mostly irrelevant for this argument anyway, as it only
affects EAPI="0", which nobody will debate both schemes can handle.

[4] If this is unclear, consider the following (inefficient)
construction of a set of ebuilds of type 2 and a corresponding
algorithm, given a set of type 1:
Take the set of ebuilds, transform to type 2; let this be the new set
of ebuilds.
Take the given type 1 algorithm, and produce the modified algorithm as
follows:
Given the type 1 algorithm, take the set of ebuilds of type 2,
transform to type 1, and run the algorithm on the properly formatted
ebuilds.
Our mapping is 1-1 and onto. We are comparing the result of running
the type 1 algorithm directly, and running the type 1 algorithm on the
ebuild having the mapping and it's inverse applied. The result must be
the same for any algorithm satisfying our restrictions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoPTrwACgkQRQqsawN7JJSefwCaAunc1F/iGV0FITN9W8EwUZkZ
vHQAoIbcbl4cIwjWjeILSfpSFj5yG17Z
=DVZJ
-----END PGP SIGNATURE-----