Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Zac Medico <zmedico@gentoo.org>]

-----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-----