Ciaran McCreesh wrote:
> On Wed, 19 Dec 2007 10:26:16 +0000
> Steve Long <[EMAIL PROTECTED]> wrote:
>> Are you really telling me you are going to write _one_ ebuild
>> with /that/ god-awful hackery in it?
>
> Are you really suggesting that no-one ever will?
>
They won't if the spec and the docs say it's restricted to a single
instance, which can be checked trivially by repoman. The example given was
contrived and not at all representative imo; for instance one could as
easily do the same kind of thing with DESCRIPTION, but it would be of
little use and just add confusion to no purpose.
>> Sticking to a single EAPI="xx" format in the ebuild means we don't
>> have the *hack* of duplicating information in the filename (and the
>> whole {pre,post}src issue, QA checks for human error since this is
>> redundant info) simply to avoid parsing a config file.
>
> There is no duplication of information, nor redundancy.
>
So what were the QA checks you mentioned to confirm that the same EAPI is
set in both the filename and the ebuild, for-- if not integrity of
duplicated data?
> The pre/post source issue exists regardless of how EAPI is set -- it's
> just that with filename EAPIs, you aren't restricted to post source
> changes.
And what benefit does that provide, besides making it easier for your
package manager?
(I note this is a technical consideration of the implementation, given as a
reason to change a clean API-- with consequences for workflow.)
> It's explicit in the GLEP because it's important that package
> mangers get it right, but it's not a new issue.
>
Sure.
> Ebuilds are not config files.
>
Indeed not, but they can be parsed as such for simple, core, metadata.
> Really. It's a heck of a lot cleaner in the filename suffix.
>
Nah, it's an awful hack and you know it. It has nothing to do with package
naming and is unnecessary exposure of internal data. -rN is ok, and there
are rules on when and when not to bump rev; this is not. It's much cleaner
specified as part of the ebuild in the same way as DESCRIPTION, so long as
it is only specified once.
Or do you see some real benefit to specifying EAPI more than once as in the
example? If so, please share it.
--
[EMAIL PROTECTED] mailing list
