[gentoo-dev] [RFC] EAPI 2 Draft

[gentoo-dev] [RFC] EAPI 2 Draft

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

Please review and discuss the following features which are proposed
for inclusion EAPI 2. As mentioned in my previous email [1], in
planning for this EAPI bump, we should strike a balance somewhere
in-between everything that we'd like to have and whatever we can
implement and agree on in a short period of time. It doesn't make a
lot of sense to delay the EAPI bump too much for implementation or
debate of new features, since those features can simply be reserved
for EAPI 3.

Refer to the html documentation [2] for addition information about
the proposed EAPI 2 extensions which are summarized here:

 * The 'doman' helper function recognizes language codes in man page
   source files, and uses them to generate an appropriate
   installation path.

 * The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
   extensions, for interoperability with gitweb.

 * The meaning of the !atom blocker syntax now implies that
   temporary simultaneous installation of conflicting packages is
   allowed [3].

 * A new !!atom blocker syntax is now supported, for use in special
   cases in which temporary simultaneous installation of conflicting
   packages should not be allowed.

 * Dependency atoms can be constrained to match specific USE flag
   states, including USE conditional expressions embedded within
   the atoms themselves.

 * SRC_URI supports a syntax extension which allows customization
   of output file names by using a "->" operator.

 * A new src_prepare phase function is called after src_unpack.

 * The old src_compile phase function is split into separate
   src_configure and src_compile fuctions.

 * Default phase function implementations for the current EAPI are
   accessible via a function having a name that begins with default_
   and ends with the respective phase function name.

 * Default phase function implementations for older EAPIs are
   accessible via functions having names that start with 'eapi',
   followed by the EAPI value.

 * The default phase function implementation for the currently
   executing phase is accessible as a function named 'default'.

Many of the above extensions have already been discussed in the
previous thread [1], so please continue discussion there if
necessary. You can file bugs for any additional features that you'd
like to add and mark them as blockers of bug 174380 [4].

[1]
http://archives.gentoo.org/gentoo-dev/msg_2ed72695ac75d0f80ddd579ef55c320a.xml
[2]
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-2-draft
[3]
http://archives.gentoo.org/gentoo-dev/msg_2551bea5c002093d5bacc26723208d93.xml
[4] http://bugs.gentoo.org/show_bug.cgi?id=174380
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjAZ/sACgkQ/ejvha5XGaO3FACfVDzAByYYfU9buY7oJo2ytc/K
lJQAn1oLi0uknAdPhVW7hELDT1FXvXX5
=K/em
-----END PGP SIGNATURE-----

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

[David Leverton]

2008/9/4 Zac Medico <zmedico@gentoo.org>:
>  * 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"

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

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Leverton wrote:
> 2008/9/4 Zac Medico <zmedico@gentoo.org>:
>>  * 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.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjA3WUACgkQ/ejvha5XGaOpJgCbBUuFc2POX2nE9An065fC+b2z
zTsAoIXp+CyP6Dy15OlcdYjNktoo7/Hq
=xJss
-----END PGP SIGNATURE-----

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

[David Leverton]

2008/9/5 Zac Medico <zmedico@gentoo.org>:
> 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.

But is it so much simpler as to justify adding a special
gitweb-specific hack to the package managers?

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

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Leverton wrote:
> 2008/9/5 Zac Medico <zmedico@gentoo.org>:
>> 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.
> 
> But is it so much simpler as to justify adding a special
> gitweb-specific hack to the package managers?

Well, it's not much different from the existing file extension logic
that's already built into the unpack function. I think what really
matters is whether or not the majority of people see it as a useful
extension.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjA4iMACgkQ/ejvha5XGaOPxwCfWolOw1zC+VbgrGrFQXqRwoXn
vDoAoOLGL+PXhyCb2+cmAI4INLfO9reS
=TXwO
-----END PGP SIGNATURE-----

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote:
> David Leverton wrote:
> > 2008/9/5 Zac Medico <zmedico@gentoo.org>:
> >> 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.
> > 
> > But is it so much simpler as to justify adding a special
> > gitweb-specific hack to the package managers?
> 
> Well, it's not much different from the existing file extension logic
> that's already built into the unpack function. I think what really
> matters is whether or not the majority of people see it as a useful
> extension.

I'm wondering why would one fetch a tarball instead of using git.eclass
which is much better for both upstream and users (in terms of bandwidth
and resources usage).

- ferdy


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

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

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

Hi,

Zac Medico <zmedico@gentoo.org>:
> David Leverton wrote:
> > 2008/9/4 Zac Medico <zmedico@gentoo.org>:
> >>  * 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
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Alec Warner]

On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico <zmedico@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Leverton wrote:
>> 2008/9/5 Zac Medico <zmedico@gentoo.org>:
>>> 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.
>>
>> But is it so much simpler as to justify adding a special
>> gitweb-specific hack to the package managers?
>
> Well, it's not much different from the existing file extension logic
> that's already built into the unpack function. I think what really
> matters is whether or not the majority of people see it as a useful
> extension.

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"

>
> - --
> Thanks,
> Zac
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkjA4iMACgkQ/ejvha5XGaOPxwCfWolOw1zC+VbgrGrFQXqRwoXn
> vDoAoOLGL+PXhyCb2+cmAI4INLfO9reS
> =TXwO
> -----END PGP SIGNATURE-----
>
>

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

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

On Friday 05 September 2008, Fernando J. Pereda wrote:
> On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote:
> > David Leverton wrote:
> > > 2008/9/5 Zac Medico <zmedico@gentoo.org>:
> > >> 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.
> > >
> > > But is it so much simpler as to justify adding a special
> > > gitweb-specific hack to the package managers?
> >
> > Well, it's not much different from the existing file extension
> > logic that's already built into the unpack function. I think what
> > really matters is whether or not the majority of people see it as a
> > useful extension.
>
> I'm wondering why would one fetch a tarball instead of using
> git.eclass which is much better for both upstream and users (in terms
> of bandwidth and resources usage).

How is using the eclass better for bandwidth usage? It won't allow for 
mirroring, and all users would have to checkout the repository from one 
place. Furthermore, you cannot have (signed) Manifests that allow 
integrity checks.

I wonder if that is an issue in gitweb in general: Will it generate the 
same tarball every time? If not, that will create issues with users not 
using gentoo mirrors, or the mirroring system itself (because the dev 
could commit a Manifest for another file than the server delivers 
later).

For what it's worth, I also see no reason to double functionality for 
one special case where we also create a solution for the more general 
one.

Robert

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

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

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Buchholz wrote:
> How is using the eclass better for bandwidth usage? It won't allow for 
> mirroring, and all users would have to checkout the repository from one
> place. Furthermore, you cannot have (signed) Manifests that allow 
> integrity checks.

- From what I understand of the idea, the eclass will just change the
SRC_URI field from the first case (sf=tgz) to the second case (->).
Eclasses have to be sourced before the SRC_URI is determined because
they can already add (and presumably alter) elements of the SRC_URI
variable.  So I'm not sure how this would directly affect mirroring or
manifests any more than simply using the -> notation?  Could you explain
what you mean when you say it won't allow for mirroring?

Generating different tarballs is much more of an issue, and would impact
on manifests too.  I guess it's a try-it-and-see situation...

Either way, it seems like the eclass idea would be a good compromise for
those that don't want gitweb specific workarounds in the package
manager, but would like to allow the flexibility for people who do?

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV
xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC
=crVS
-----END PGP SIGNATURE-----

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

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Buchholz wrote:
> How is using the eclass better for bandwidth usage? It won't allow for 
> mirroring, and all users would have to checkout the repository from one
> place. Furthermore, you cannot have (signed) Manifests that allow 
> integrity checks.

- From what I understand of the idea, the eclass will just change the
SRC_URI field from the first case (sf=tgz) to the second case (->).
Eclasses have to be sourced before the SRC_URI is determined because
they can already add (and presumably alter) elements of the SRC_URI
variable.  So I'm not sure how this would directly affect mirroring or
manifests any more than simply using the -> notation?  Could you explain
what you mean when you say it won't allow for mirroring?

Generating different tarballs is much more of an issue, and would impact
on manifests too.  I guess it's a try-it-and-see situation...

Either way, it seems like the eclass idea would be a good compromise for
those that don't want gitweb specific workarounds in the package
manager, but would like to allow the flexibility for people who do?

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV
xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC
=crVS
-----END PGP SIGNATURE-----

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

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

On Friday 05 September 2008, Mike Auty wrote:
> From what I understand of the idea, the eclass will just change the
> SRC_URI field from the first case (sf=tgz) to the second case (->).
> Eclasses have to be sourced before the SRC_URI is determined because
> they can already add (and presumably alter) elements of the SRC_URI
> variable.  So I'm not sure how this would directly affect mirroring
> or manifests any more than simply using the -> notation?  Could you
> explain what you mean when you say it won't allow for mirroring?

I was under the impression ferdy meant to use live checkouts instead of 
tarballs. I might have misunderstood that.


> Generating different tarballs is much more of an issue, and would
> impact on manifests too.  I guess it's a try-it-and-see situation...

I think it would be a better idea to check whether this feature actually 
works before implementing. I just don't know a gitweb site that tars up 
revisions / tags to test.


Robert

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

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

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

Alec Warner kirjoitti:
> On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico <zmedico@gentoo.org> wrote:
> David Leverton wrote:
>>>> 2008/9/5 Zac Medico <zmedico@gentoo.org>:
>>>>> 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.
>>>> But is it so much simpler as to justify adding a special
>>>> gitweb-specific hack to the package managers?
> Well, it's not much different from the existing file extension logic
> that's already built into the unpack function. I think what really
> matters is whether or not the majority of people see it as a useful
> extension.
> 
>> 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"
> 

I think this is better than having it in EAPI2. You could even move 
SRC_URI above inherit and automatically transform the URI.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

On Friday 05 September 2008 00:58:05 Zac Medico wrote:
>  * Default phase function implementations for older EAPIs are
>    accessible via functions having names that start with 'eapi',
>    followed by the EAPI value.

Based on the lack of use cases or further responses to [1] I would suggest
removing this feature from eapi 2.

[1] http://archives.gentoo.org/gentoo-dev/msg_419885810c399b4cebbc62bd96081f87.xml

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Steve Long]

Christian Faulhammer wrote:

> Zac Medico <zmedico@gentoo.org>:
>> 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.

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

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Sat, Sep 06, 2008 at 12:43:12PM +0100, Steve Long wrote:
> Christian Faulhammer wrote:
> 
> > Zac Medico <zmedico@gentoo.org>:
> >> 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Alec Warner]

On Sat, Sep 6, 2008 at 4:43 AM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Christian Faulhammer wrote:
>
>> Zac Medico <zmedico@gentoo.org>:
>>> 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

>
>
>
>

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

[Markus Ullmann]

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] [RFC] EAPI 2 Draft

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On 00:39 Fri 05 Sep     , Zac Medico wrote:
> David Leverton wrote:
> > 2008/9/5 Zac Medico <zmedico@gentoo.org>:
> >> 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.
> > 
> > But is it so much simpler as to justify adding a special
> > gitweb-specific hack to the package managers?
> 
> Well, it's not much different from the existing file extension logic
> that's already built into the unpack function. I think what really
> matters is whether or not the majority of people see it as a useful
> extension.

I'm not writing new ebuilds from scratch or changing SRC_URI of existing 
ebuilds so often (especially those with this particular requirement) 
that there's any meaningful barrier to using arros instead of having 
this custom thing.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

[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@rathaus.eclipse.co.uk>
> wrote:
>> Christian Faulhammer wrote:
>>
>>> Zac Medico <zmedico@gentoo.org>:
>>>> 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."

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

[Steve Long]

Thomas Anderson wrote:

> On Sat, Sep 06, 2008 at 12:43:12PM +0100, Steve Long wrote:
>> Christian Faulhammer wrote:
>> 
>> > Zac Medico <zmedico@gentoo.org>:
>> >> 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.

You're confusing the code which implements, with the API thus provided. It's
totally irrelevant whether the same code handles the functionality or not.
(That's what encapsulation is about.)

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

[Alec Warner]

On Mon, Sep 8, 2008 at 2:46 PM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Alec Warner wrote:
>
>> On Sat, Sep 6, 2008 at 4:43 AM, Steve Long <slong@rathaus.eclipse.co.uk>
>> wrote:
>>> Christian Faulhammer wrote:
>>>
>>>> Zac Medico <zmedico@gentoo.org>:
>>>>> 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