FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-04-2012, 08:12 PM
"Andreas K. Huettel"
 
Default src_fetch() phase function to support VCS fetching

> 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 data transfer only.

--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing
 
Old 09-05-2012, 07:25 AM
Ciaran McCreesh
 
Default src_fetch() phase function to support VCS fetching

On Tue, 4 Sep 2012 19:23:51 +0200
Michał Górny <mgorny@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.)
>
> They either stay with src_unpack() or do 'cvs up' in src_fetch()
> and just copy files over in src_unpack(). Anyway, that's what they do
> now -- update the copy in distfiles/cvs-src and then copy it.

This doesn't work if we have, for example, foo:1 and foo:2 both using
the same SCM repository, but different branches. Much as we'd like to
pretend that everyone uses Git, we can't really ignore this case...

So we have to decide: do we make the src_fetch copy the data somewhere
after all, or do we require that eclasses do something obscene to avoid
this?

--
Ciaran McCreesh
 
Old 09-05-2012, 08:38 AM
Michał Górny
 
Default src_fetch() phase function to support VCS fetching

On Wed, 5 Sep 2012 08:25:54 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 4 Sep 2012 19:23:51 +0200
> Michał Górny <mgorny@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.)
> >
> > They either stay with src_unpack() or do 'cvs up' in src_fetch()
> > and just copy files over in src_unpack(). Anyway, that's what they
> > do now -- update the copy in distfiles/cvs-src and then copy it.
>
> This doesn't work if we have, for example, foo:1 and foo:2 both using
> the same SCM repository, but different branches. Much as we'd like to
> pretend that everyone uses Git, we can't really ignore this case...
>
> So we have to decide: do we make the src_fetch copy the data somewhere
> after all, or do we require that eclasses do something obscene to
> avoid this?

Eclasses have to handle themselves, if we are supporting this. There's
no point in bloating the solution for 1 theoretical package on 1000
which doesn't even exist.

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 existing tools anyway.

Well, even I doubt eclasses need to do something obscene. The need for
that is so small that I believe if someone was crazy enough, he could
just set an appropriate storedir in ebuild.

--
Best regards,
Michał Górny
 
Old 09-05-2012, 09:07 AM
Ulrich Mueller
 
Default src_fetch() phase function to support VCS fetching

>>>>> 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 the emacs-24 branch,
sharing a common repository.

> 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 existing tools anyway.

I haven't notice any breakage with it.

Ulrich
 
Old 09-05-2012, 10:07 AM
Michał Górny
 
Default src_fetch() phase function to support VCS fetching

On Wed, 5 Sep 2012 11:07:44 +0200
Ulrich Mueller <ulm@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 app-editors/emacs-vcs. For example, we
> used to have live ebuilds for the trunk and for the emacs-24 branch,
> sharing a common repository.

Doesn't bzr actually work alike git? i.e. keep all commits when
switching branches?

--
Best regards,
Michał Górny
 
Old 09-05-2012, 10:29 AM
Ulrich Mueller
 
Default src_fetch() phase function to support VCS fetching

>>>>> On Wed, 5 Sep 2012, Michał Górny wrote:

> On Wed, 5 Sep 2012 11:07:44 +0200
> Ulrich Mueller <ulm@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 app-editors/emacs-vcs. For example, we
>> used to have live ebuilds for the trunk and for the emacs-24 branch,
>> sharing a common repository.

> Doesn't bzr actually work alike git? i.e. keep all commits when
> switching branches?

Actually, bzr.eclass uses branches without a working tree (what would
be called a "bare repository" in the Git world). There's no need to
switch branches.

Ulrich
 
Old 09-05-2012, 10:45 AM
"Andreas K. Huettel"
 
Default src_fetch() phase function to support VCS fetching

> 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 existing tools anyway.

This is done large-scale for all KDE ebuilds (in the KDE overlay) to support
master and KDE/4.x stable branch. Most use git, so no problem; some (still)
use subversion but will be migrated upstream soon(?).

Other examples are libreoffice (main tree, git) and cups (main tree,
subversion).

--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing
 
Old 09-05-2012, 10:49 AM
Ciaran McCreesh
 
Default src_fetch() phase function to support VCS fetching

On Wed, 05 Sep 2012 12:45:16 +0200
"Andreas K. Huettel" <dilfridge@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 that re-fetching the branches back and forth is a correct
> > solution. And it breaks existing tools anyway.
>
> This is done large-scale for all KDE ebuilds (in the KDE overlay) to
> support master and KDE/4.x stable branch. Most use git, so no
> problem; some (still) use subversion but will be migrated upstream
> soon(?).
>
> Other examples are libreoffice (main tree, git) and cups (main tree,
> subversion).

I guess that's a pretty comprehensive "we need to do this properly"
then.

--
Ciaran McCreesh
 
Old 09-05-2012, 11:00 AM
Michał Górny
 
Default src_fetch() phase function to support VCS fetching

On Wed, 5 Sep 2012 11:49:03 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 05 Sep 2012 12:45:16 +0200
> "Andreas K. Huettel" <dilfridge@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 that re-fetching the branches back and forth is a
> > > correct solution. And it breaks existing tools anyway.
> >
> > This is done large-scale for all KDE ebuilds (in the KDE overlay) to
> > support master and KDE/4.x stable branch. Most use git, so no
> > problem; some (still) use subversion but will be migrated upstream
> > soon(?).
> >
> > Other examples are libreoffice (main tree, git) and cups (main
> > tree, subversion).
>
> 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?

--
Best regards,
Michał Górny
 
Old 09-05-2012, 11:07 AM
Ciaran McCreesh
 
Default src_fetch() phase function to support VCS fetching

On Wed, 5 Sep 2012 13:00:05 +0200
Michał Górny <mgorny@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 to work out how to deal with this at least
for Subversion, and probably for CVS too... As much as we'd like to, we
can't just roll out a src_fetch without eclass changes. This doesn't
appear to be a trivial feature to provide.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 10:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org