[gentoo-dev] Re: Re: [RFC] EAPI 2 Draft

[Steve Long]

Alec Warner wrote:

> On Sat, Sep 6, 2008 at 4:43 AM, Steve Long <slong@××××××××××××××××××.uk>
> wrote:
>> Christian Faulhammer wrote:
>>
>>> Zac Medico <zmedico@g.o>:
>>>> Both approaches are essentially equivalent but it's a little simpler
>>>> for ebuild writer if they don't have to customize the output file
>>>> name.
>>>
>>>  One needs exceptions for all kind of systems, for example I had to
>>> workaround Trac which adds ?format=raw to a tarball URI.  There seems
>>> to be a solution in Trac as the guys from fedarahosted fixed the two I
>>> needed (tmpwatch, mlocate).  So the -> operator is quite useful and I
>>> agree with David that the functionality is doubled.
>>>
>> Clearly src-uri transformation is useful. Others have given examples of
>> how it would be useful to an eclass. Irrespective of how the actual
>> transform is done in the ;sf=tbz2 case, both _are_ valid use-cases.
>>
>> As such I don't see any reason not to put it in the EAPI. Future
>> extensions can be trialled in eutils, and these can both be allowed
>> syntax for other package managers to comply with (one implementation has
>> already been given) and ebuild devs to feel comfortable using in the
>> Gentoo tree. Why slow the innovation down? It's good enough for use
>> as-is.
>
> Because then we have to wait for all the PM's to implement this
> magical code; where if we put it in eutils
> we can use it right now (and most overlays can use it too).  'Why slow
> the innovation down?' :)
>
Eh? I thought it was for the portage team to define the EAPI for Gentoo,
published so that others can interoperate? And how are other Package
Managers going to feel if they have to keep checking eutils for what it
does to stay current with the tree, as opposed to looking in the EAPI doc?

This is wandering into -project territory however, imo, since there's no
_technical_ reason not to allow the proposed usage in the EAPI. All I've
heard so far is "we might want to extend it later."