-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Petteri Räty wrote: > Let's try something new. I would like to get opinions from as many > people as possible about GLEP 55 and alternatives listed here in order > to get some idea what the general developer pool thinks. Everyone is > only allowed to post a single reply to this thread in order to make it > easy to read through. The existing thread should be used for actual > discussion about the GLEP and the alternatives. This should be a useful > experiment to see if we can control ourselves :) > > My notes so far: > > 1) Status quo > - does not allow changing inherit > - bash version in global scope > - global scope in general is quite locked down
I don't want to stick with the status quo since being able to probe the EAPI without sourcing the ebuild is quite useful. Among other things, it allows the package manager to avoid the overhead of sourcing the ebuild in case neither the EAPI nor the cache format is understood, which solves a problem [1] discussed in the thread about adding DIGESTS data to the cache. > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild-<eapi> > - ignored by current Portage I'd prefer not to introduce an infinite series of file extensions. To me that just seems too unconventional. > b) .<eapi>.ebuild > - current Portage does not work with this > c) .<eapi>.<new extension> > - ignored by current Portage Either of these is fine with me. > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache I think it's alright to change the EAPI in an existing ebuild. Since you can simply parse the EAPI instead of sourcing the ebuild, having a valid cache isn't so important. > - Does not allow changing versioning rules unless version becomes a > normal metadata variable As said by Richard [2], it's alright to change the version rules. Since you can simply parse the EAPI, it's not appreciably less accessible than if the EAPI is embedded in the file name. > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked Accessing the cache or parsing the EAPI is relatively inexpensive compared to sourcing the ebuild, so it's not really a problem. Again, once you can parse the EAPI, it's not appreciably less accessible then if the EAPI is embedded in the file name. > a) <new extension> I think a new extension is preferable to a directory. > b) new subdirectory like ebuilds/ > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository > c) .ebuild in current directory > - needs one year wait You really only need to wait in order to avoid things like warning messages about invalid name/version (if you want to do naming convention changes). If the name/version appear valid, the existing cache entries will prevent the ebuild from being sourced by existing versions of portage (as long as the timestamp of the cache entry matches the timestamp of the ebuild). [1] http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml [2] http://archives.gentoo.org/gentoo-dev/msg_bf3aa0199bb521b263b19b4997a0429c.xml - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmmKkoACgkQ/ejvha5XGaP+2gCfZvkKYypzKydZ+1+sShQkJKr3 ObAAoNr1r9E9eNRCAisahJyqcu6FDV3S =kj8B -----END PGP SIGNATURE-----
