-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2012 02:50 PM, Michał Górny wrote:
On Thu, 6 Sep 2012 09:49:13 -0700
Brian Harring ferri...@gmail.com wrote:
One additional thought- re: the scenarios where we don't fetch to an
intermediate location, then transfer that contents into
On Tue, Sep 11, 2012 at 06:36:46PM -0400, Rick Zero_Chaos Farina wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2012 02:50 PM, Micha?? G??rny wrote:
On Thu, 6 Sep 2012 09:49:13 -0700
Brian Harring ferri...@gmail.com wrote:
One additional thought- re: the scenarios
CM == Ciaran McCreesh ciaran.mccre...@googlemail.com writes:
CM This doesn't work if we have, for example, foo:1 and foo:2 both using
CM the same SCM repository, but different branches.
The subversion eclass already handles that; it stores in $distfiles/$P/$branch.
The cvs eclass also could do
On Wed, Sep 05, 2012 at 12:07:22PM +0100, Ciaran McCreesh wrote:
On Wed, 5 Sep 2012 13:00:05 +0200
Micha?? G??rny mgo...@gentoo.org wrote:
I guess that's a pretty comprehensive we need to do this properly
then.
Did I say we don't need to? We have the two eclasses which need to do
On Thu, 6 Sep 2012 09:49:13 -0700
Brian Harring ferri...@gmail.com wrote:
One additional thought- re: the scenarios where we don't fetch to an
intermediate location, then transfer that contents into ${WORKDIR},
while a better name is needed, something along the lines of
Yes. The manager can still parallelize prefetching, only consuming a build
job slot post fetch.
On Sep 6, 2012 11:49 AM, Michał Górny mgo...@gentoo.org wrote:
On Thu, 6 Sep 2012 09:49:13 -0700
Brian Harring ferri...@gmail.com wrote:
One additional thought- re: the scenarios where we don't
On Tue, 4 Sep 2012 19:23:51 +0200
Michał Górny mgo...@gentoo.org wrote:
The 'checking out' language for src_unpack() sounds like it assumes
a DVCS such as mercurial or git. What about cvs or svn, where
fetching is also checking out? (This is probably a trivial thing to
clear up, though.)
On Wed, 5 Sep 2012 08:25:54 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Tue, 4 Sep 2012 19:23:51 +0200
Michał Górny mgo...@gentoo.org wrote:
The 'checking out' language for src_unpack() sounds like it
assumes a DVCS such as mercurial or git. What about cvs or svn,
On Wed, 5 Sep 2012, Michał Górny wrote:
And yes, it is *very* unlikely that someone uses a slotted live
ebuild with two branches being meaningful and managed in the same
repo.
We do that all the time for app-editors/emacs-vcs. For example, we
used to have live ebuilds for the trunk and for
On Wed, 5 Sep 2012 11:07:44 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Wed, 5 Sep 2012, Michał Górny wrote:
And yes, it is *very* unlikely that someone uses a slotted live
ebuild with two branches being meaningful and managed in the same
repo.
We do that all the time for
On Wed, 5 Sep 2012, Michał Górny wrote:
On Wed, 5 Sep 2012 11:07:44 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Wed, 5 Sep 2012, Michał Górny wrote:
And yes, it is *very* unlikely that someone uses a slotted live
ebuild with two branches being meaningful and managed in the same
And yes, it is *very* unlikely that someone uses a slotted live ebuild
with two branches being meaningful and managed in the same repo. Even
if such thing exists, it is broken anyway because you can't say that
re-fetching the branches back and forth is a correct solution. And it
breaks
On Wed, 05 Sep 2012 12:45:16 +0200
Andreas K. Huettel dilfri...@gentoo.org wrote:
And yes, it is *very* unlikely that someone uses a slotted live
ebuild with two branches being meaningful and managed in the same
repo. Even if such thing exists, it is broken anyway because you
can't say
On Wed, 5 Sep 2012 11:49:03 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Wed, 05 Sep 2012 12:45:16 +0200
Andreas K. Huettel dilfri...@gentoo.org wrote:
And yes, it is *very* unlikely that someone uses a slotted live
ebuild with two branches being meaningful and managed
On Wed, 5 Sep 2012 13:00:05 +0200
Michał Górny mgo...@gentoo.org wrote:
I guess that's a pretty comprehensive we need to do this properly
then.
Did I say we don't need to? We have the two eclasses which need to do
this properly, right? So what's your problem?
The problem is that we need
On Wed, 5 Sep 2012 12:07:22 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Wed, 5 Sep 2012 13:00:05 +0200
Michał Górny mgo...@gentoo.org wrote:
I guess that's a pretty comprehensive we need to do this
properly then.
Did I say we don't need to? We have the two eclasses
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/09/12 07:25 AM, Michał Górny wrote:
Finally, I don't think eclasses are really forced to use
src_fetch() from day one. src_unpack() will still work for them,
and we can adjust them gradually.
...except for the fact that the whole point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/2012 12:43 PM, Michał Górny wrote:
Hello,
As Sid Hayn raised today on #gentoo-portage, it would be useful to
If you insist on using real names mine is Rick ;-)
finally have portage able to fetch updates from VCS-es independently
of
On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny mgo...@gentoo.org wrote:
Hello,
As Sid Hayn raised today on #gentoo-portage, it would be useful to
finally have portage able to fetch updates from VCS-es independently
of src_unpack(). This could be used, for example, on machines
temporarily
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/2012 12:43 PM, Michał Górny wrote:
Hello,
As Sid Hayn raised today on #gentoo-portage, it would be useful to
finally have portage able to fetch updates from VCS-es independently
of src_unpack(). This could be used, for example, on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/2012 01:02 PM, Michael Mol wrote:
On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny mgo...@gentoo.org wrote:
Hello,
As Sid Hayn raised today on #gentoo-portage, it would be useful to
finally have portage able to fetch updates from VCS-es
On Tue, 4 Sep 2012 13:02:36 -0400
Michael Mol mike...@gmail.com wrote:
On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny mgo...@gentoo.org
wrote:
Hello,
As Sid Hayn raised today on #gentoo-portage, it would be useful to
finally have portage able to fetch updates from VCS-es independently
On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote:
I believe the easiest (and honestly most sane) method is to simply have
src_fetch in the live classes check for needed deps and die (with a
please emerge blah) if deps are not found. Adding something like
FDEPEND just seems to be getting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/09/12 01:32 PM, Zac Medico wrote:
On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote:
I believe the easiest (and honestly most sane) method is to
simply have src_fetch in the live classes check for needed deps
and die (with a please
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/2012 03:56 PM, Ian Stakenvicius wrote:
On 04/09/12 01:32 PM, Zac Medico wrote:
On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote:
I believe the easiest (and honestly most sane) method is to
simply have src_fetch in the live classes
On Tue, 04 Sep 2012 15:56:54 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/09/12 01:32 PM, Zac Medico wrote:
On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote:
I believe the easiest (and honestly most sane) method is to
simply
Just looking into the future here; would things like archivers or
other helpers used by src_unpack move to FDEPEND as well? or would
this be limited solely to tools that data transfer?
We should keep the data transfer and the unpack phase clearly separated. So,
this would best really be for
27 matches
Mail list logo
