While it's may be a good idea to set EAPI inside filename and if we ever
decide on this, consider different implementation.
I really dislike idea of EAPI-suffixed extensions. It's easier for me
(and I think for others too) to differentiate ebuilds between other
files in directory when ebuild files have common suffix. We are people
so we should simplify things that are not hidden under the hood, like
this...
This hack is just to solve portage problem which does not ignore .ebuild
files which does not follow pkg-ver.ebuild syntax and suggested solution
is not the only solution. Other possibilities are, which I like more:
1. USE pkg-ver.EAPI-ebuild
2. USE pkg-ver${EAPITAG}EAPI.ebuild
Here ${EAPITAG} is string to simplify parsing EAPI from
version. E.g. EAPITAG could be _eapi or EAPI or something
else.
Although second solution does not solve the problem with portage I like
it more, as we all have habit to look at .ebuild suffix. But this is
different problem. Once we define good NEW format for filename it's
possible to decide on transition path which allows us to use eapi right
now. E.g. start using this format only with .ebuild-ng suffix and after
three years pass it's possible to rename all .ebuild-ng into .ebuild.
And another idea which was already mentioned somewhere in this thread. I
think .ebuild should be written only in BASH. Again if we ever decide to
use ebuilds with different syntax we should use different suffix.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
