On Mon, Sep 8, 2008 at 2:46 PM, Steve Long <[EMAIL PROTECTED]> wrote: > Alec Warner wrote: > >> On Sat, Sep 6, 2008 at 4:43 AM, Steve Long <[EMAIL PROTECTED]> >> wrote: >>> Christian Faulhammer wrote: >>> >>>> Zac Medico <[EMAIL PROTECTED]>: >>>>> 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?
I am unsure whose job it is to define EAPI; but I'll move on to your next point. If we put a function in an eclass; why would other package managers have to keep checking the eclass? They are not bundling the eclass with their package manager; the eclass comes with the tree (and ergo, the ebuilds that utilize said eclass). If an ebuild wants to use it: ---------------------------------- inherit example example_src_uri_gitize ---------------------------------- The above code confirms to PMS and is package manager agnostic. Does that make sense? -Alec
