On 2007/12/18, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> Well, users shouldn't really be doing anything with .ebuild files...
As a user, i often end reading part of some ebuilds to get a clue about
what the generic "foo" USE flag does in a particular package ("qgrep -A3
-B2 -Nx '\<foo\>' cat/pkg-ver" or alike).
> Or if by users you mean developers, I'd say it's considerably less
> inconvenient than having to remember arbitrary syntax restrictions...
"EAPI=foo must come first" is only one restriction, not several.
It's really easy enough to remember, and devs are more or less about to
conform to it anyway (since EAPI must come prior to "inherits", and
it's in skel.ebuild, etc.). It's also easy for package managers to
remind it as soon a dev tries to do anything with an offending ebuild
he has just written.
So please don't make it sound overly complicated when it's not.
You call my proposal a "nasty hack", but seriously, GLEP55's way of
putting one particular metadata in the file name rather than the file
contents whereas it's not discriminating for atoms (the reason you need
to forbid "foo-1.ebuild-blah" and "foo-1.ebuild-booh" existing in the
same dir) is at least as ugly (well, at least it's debatable).
And yes, you can answer that there are already such rules in
application, like "foo-1-r0.ebuild" not being allowed together with
"foo-1.ebuild", but my answer would be that's it's not a reason to make
things worst. In my ideal world, there shouldn't exists several
equal versions with different syntaxes(-r0 would not exists, _p would
be less than _p0, etc.), and a versionned atom should only correspond to
one single possible file name.
--
TGL.
--
[EMAIL PROTECTED] mailing list
