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@lists.gentoo.org mailing list
