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 wrote:
> >
> >> One additional thought- re: the scenarios where we
-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 wrote:
>
>> One additional thought- re: the scenarios where we don't fetch to an
>> intermediate location, then transfer that contents into ${WORKDIR},
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" wrote:
> On Thu, 6 Sep 2012 09:49:13 -0700
> Brian Harring wrote:
>
> > One additional thought- re: the scenarios where we don't fetch to an
> > intermediate l
On Thu, 6 Sep 2012 09:49:13 -0700
Brian Harring 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
> RESTRICT=fetches-into-workdir come
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 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
> "CM" == Ciaran McCreesh 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 so.
-JimC
--
James
-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 poin
On Wed, 5 Sep 2012 12:07:22 +0100
Ciaran McCreesh wrote:
> On Wed, 5 Sep 2012 13:00:05 +0200
> Michał Górny 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 properl
On Wed, 5 Sep 2012 13:00:05 +0200
Michał Górny 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 to work ou
On Wed, 5 Sep 2012 11:49:03 +0100
Ciaran McCreesh wrote:
> On Wed, 05 Sep 2012 12:45:16 +0200
> "Andreas K. Huettel" 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
On Wed, 05 Sep 2012 12:45:16 +0200
"Andreas K. Huettel" 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 that re-fetchi
> 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 ex
> On Wed, 5 Sep 2012, Michał Górny wrote:
> On Wed, 5 Sep 2012 11:07:44 +0200
> Ulrich Mueller 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 sa
On Wed, 5 Sep 2012 11:07:44 +0200
Ulrich Mueller 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 app-edito
> 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 an
On Wed, 5 Sep 2012 08:25:54 +0100
Ciaran McCreesh wrote:
> On Tue, 4 Sep 2012 19:23:51 +0200
> Michał Górny 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? (T
On Tue, 4 Sep 2012 19:23:51 +0200
Michał Górny 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.)
>
> They e
> 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 fo
On Tue, 04 Sep 2012 15:56:54 -0400
Ian Stakenvicius 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 have
-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 c
-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 "pl
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 ge
On Tue, 4 Sep 2012 13:02:36 -0400
Michael Mol wrote:
> On Tue, Sep 4, 2012 at 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 c
-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 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 independentl
-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 m
On Tue, Sep 4, 2012 at 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 machines
> temporarily connected to the
-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
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 connected to the network -- one would then fetch files
while connected to the net
28 matches
Mail list logo
