Re: [gentoo-dev] Re: GLEP 55

[Richard Freeman]

Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> Kills the upgrade path completely. No good.
>
> Lemme sum this up in layman's terms :
>
> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
> avoid that for various reasons, all 100% valid.
>
> 2) Putting the EAPI in the filename :
>
>  + it solves 1)
>  + it keeps backward compatibility because old PM won't recognize the
> filenames
>  - it's not very "pretty"
>
> 3) Putting the EAPI in metadata.xml or in another external file
>
>  + it solves 1)
>  + it keeps pretty file names
>  - it breaks backwards compatibility
>  - (specific to metadata.xml) PM will have to learn to read XML (yuck)
>
> That's about it, right?
>

You missed some options - I'll try to be honest about their pros/cons:

4) Putting EAPI inside the ebuild, but in a manner that does not require 
sourcing using bash (ie comment at top of file).

+ it solves 1)
+ it keeps pretty file names
+ syntax/implementation is trivial
- it breaks backwards compatibility (eventually - hacks might delay this)
- it does force future ebuilds to have the EAPI line in it

5) Putting EAPI inside the ebuild as in #4, but do a one-time-only 
change of the filenames.

+ it solves 1)
+ it sort-of-keeps pretty file names (two pretty extensions instead of one)
+ syntax/implementation is trivial
+ it preserves backwards compatibility
- it does force future ebuilds to have the EAPI line in it

6) Putting EAPI inside the ebuild as in #4, and do a one-time rsync 
location change

+ it solves 1)
+ the filenames don't change at all
+ syntax is trivial, future ebuilds are trivial
+ it preserves backwards compatibility
- it does force future ebuilds to have the EAPI line in it
- it seems like quite a hack - and you end up with a dummy portage tree 
sitting out there for some period of time


Personally, I tend to lean towards either just putting the EAPI in the 
filename, or putting it in the first line and breaking backwards 
compatibility.  The whole reason we're in this mess is the ebuild file 
format does not include a version field or the equivalent of extensible 
headers used in other sorts of files (tar, etc).  We've certainly broken 
backwards-compatibility before with other changes within the distro. 
All we need to do is make it easy to update to a package manager that 
fixes the break and post instructions prominently, and make sure that 
package managers support the new process for a few months before taking 
advantage of it.

Some object to parsing out the EAPI without sourcing the ebuild (only 
bash can source bash).  I disagree with this argument - every time you 
run a shell script it is sourced by something other than bash - the 
kernel has to figure out what script interpreter to use by parsing the 
first line.  There is no reason we can't use a magic number in the same 
way with the EAPI.  That isn't reason enough on its own to put the EAPI 
in the filename, but it is a start.

Most software packages store version information internal to a file 
format.  I'm actually not aware of many that put it in the filename.
-- 
gentoo-dev@l.g.o mailing list