[gentoo-dev] Re: [RFC] EAPI 2 Draft
Alec Warner schrieb: > I think the question isn't 'why is this functionality being made > available'; I think to me it is useful piece of code. > > I question its inclusion in the PM though; I would rather see it in > eutils or something similar. > > Arguably you could inherit a function from eutils that does SRC_URI > transformation for you. > > SRC_URI="foo bar baz;sf=tbz2" > src_uri_gitize > > would transform "baz;sf=tbz2" into "baz;sf=tbz2 -> baz.tar.bz2" Same applies to files that are fetched from trac so I also would question hard-coding a single use case into PM... Greetz -Jokey
Re: [gentoo-dev] Re: [RFC] EAPI 2 Draft
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?' :) -Alec > > > >
Re: [gentoo-dev] Re: [RFC] EAPI 2 Draft
On Sat, Sep 06, 2008 at 12:43:12PM +0100, Steve Long 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.
Sure they may be valid use cases, but the issue is whether the
;sf=tar.bz2 code is duplicated from '->'. I don't see any reason why you
can't use '->' to handle ;sf=tbz2, so they are duplicated. Since '->'
can be used in more circumstances(SRC_URI="http://foo.com/2.3/foo.bz2
-> ${P}.tar.bz2" comes to mind), we don't need ;sf=tbz2.
pgpD0tA0gVKlo.pgp
Description: PGP signature
[gentoo-dev] Re: [RFC] EAPI 2 Draft
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.
[gentoo-dev] Re: [RFC] EAPI 2 Draft
Hi,
Zac Medico <[EMAIL PROTECTED]>:
> David Leverton wrote:
> > 2008/9/4 Zac Medico <[EMAIL PROTECTED]>:
> >> * The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
> >> extensions, for interoperability with gitweb.
> >>
> >> * SRC_URI supports a syntax extension which allows customization
> >> of output file names by using a "->" operator.
> >
> > Is it useful to have both of these? The former seems awfully
> > specialised for a general format like ebuilds, and can be replaced
> > with
> >
> > COMMIT="1234..."
> >
> > SRC_URI="http://git.example.org/?p=foo.git;a=snapshot;h=${COMMIT};sf=tbz2
> > -> foo-${COMMIT}.tar.bz2"
>
> 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.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://www.faulhammer.org/>
signature.asc
Description: PGP signature
