On 00:39 Fri 05 Sep , Zac Medico wrote:
> David Leverton wrote:
> > 2008/9/5 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.
> >
> > But is it so much simpler
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
remo
Alec Warner kirjoitti:
On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico <[EMAIL PROTECTED]> wrote:
David Leverton wrote:
2008/9/5 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 nam
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 alt
-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
-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
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 <[EMAIL PROTECTED]>:
> > >> Both approaches are essentially equivalent but it's a little
> > >> simpler for ebuild writer if they
On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Leverton wrote:
>> 2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
>>> Both approaches are essentially equivalent but it's a little simpler
>>> for ebuild writer if they don't
On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote:
> David Leverton wrote:
> > 2008/9/5 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.
> >
> > But is it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
> 2008/9/5 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.
>
> But is it so much simpler as to jus
2008/9/5 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.
But is it so much simpler as to justify adding a special
gitweb-specific hack to the package managers?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 customizati
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
-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
14 matches
Mail list logo
