Patchwork RFC One recipe with two git repository as sources

Hi all,

I have some messy source (as the cleanup is going on), I need to pull the new
code from one repo and some files from the old one. Now in the recipes I have:

SRC_URI = "git://git@....git;protocol=ssh;name=first \
           git://git@....git;protocol=ssh;name=second"
SRCREV_FORMAT = "first-rsecond"
SRCREV_first = "ABC"
SRCREV_second = "DEF"
PV = "0.0+git${SRCPV}"
(too bad that we have inconsistency between git, gitr again)

This is all fluffy, the right things seem to be cloned but there is only one
${WORKDIR}/git and one or the other will end up in there. Somehow I think we
had something like this before but here is the proposal:

Introduce a ;destsuffix=DEST so the code will be checked out to DEST/ instead
of git/.


comments?
	holger


commit e45b5b3b917eaba42052760c82c9b4ca57670136
Author: Holger Hans Peter Freyther <holger@moiji-mobile.com>
Date:   Thu Jun 23 04:50:13 2011 +0800

    fetch2/git: Allow to specify the name of the checkout directory

On Thu, 2011-06-23 at 13:18 +0200, Holger Freyther wrote:
> -        destdir = os.path.join(destdir, "git/")
> +        destsuffix = ud.parm.get("destsuffix", "git/")
> +        print destsuffix
> +        destdir = os.path.join(destdir, destsuffix)

I think that "print" might be extraneous, but other than this your patch
looks awesome.  I think this would resolve the problem that I was having
in
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/004375.html and to which I never found a solution which didn't involve patching bitbake.

p.

On 06/23/2011 01:21 PM, Phil Blundell wrote:
> On Thu, 2011-06-23 at 13:18 +0200, Holger Freyther wrote:
>> -        destdir = os.path.join(destdir, "git/")
>> +        destsuffix = ud.parm.get("destsuffix", "git/")
>> +        print destsuffix
>> +        destdir = os.path.join(destdir, destsuffix)
> 
> I think that "print" might be extraneous, but other than this your patch
> looks awesome.  I think this would resolve the problem that I was having
> in.

great, yeah the print is bogus and the question if and how this applies to
fetch/git.py is also unresolved (i had a quick look but have not found the
dirname it uses to create the tarball).

On Thu, 2011-06-23 at 13:36 +0200, Holger Freyther wrote:
> On 06/23/2011 01:21 PM, Phil Blundell wrote:
> > On Thu, 2011-06-23 at 13:18 +0200, Holger Freyther wrote:
> >> -        destdir = os.path.join(destdir, "git/")
> >> +        destsuffix = ud.parm.get("destsuffix", "git/")
> >> +        print destsuffix
> >> +        destdir = os.path.join(destdir, destsuffix)
> > 
> > I think that "print" might be extraneous, but other than this your patch
> > looks awesome.  I think this would resolve the problem that I was having
> > in.
> 
> great, yeah the print is bogus and the question if and how this applies to
> fetch/git.py is also unresolved (i had a quick look but have not found the
> dirname it uses to create the tarball).

I'm not entirely clear on what's going on with fetch vs fetch2 at all,
in terms of whether fetch is going away at some point or the two of them
are meant to be existing in parallel.  Can one of the TSC überhackers
shed any light on what the intent is there?

p.

On 6/23/11 9:25 AM, Phil Blundell wrote:
> On Thu, 2011-06-23 at 13:36 +0200, Holger Freyther wrote:
>> On 06/23/2011 01:21 PM, Phil Blundell wrote:
>>> On Thu, 2011-06-23 at 13:18 +0200, Holger Freyther wrote:
>>>> -        destdir = os.path.join(destdir, "git/")
>>>> +        destsuffix = ud.parm.get("destsuffix", "git/")
>>>> +        print destsuffix
>>>> +        destdir = os.path.join(destdir, destsuffix)
>>>
>>> I think that "print" might be extraneous, but other than this your patch
>>> looks awesome.  I think this would resolve the problem that I was having
>>> in.
>>
>> great, yeah the print is bogus and the question if and how this applies to
>> fetch/git.py is also unresolved (i had a quick look but have not found the
>> dirname it uses to create the tarball).
> 
> I'm not entirely clear on what's going on with fetch vs fetch2 at all,
> in terms of whether fetch is going away at some point or the two of them
> are meant to be existing in parallel.  Can one of the TSC überhackers
> shed any light on what the intent is there?
> 

"fetch" is remaining for compatibility for the time being.  I believe the intent
is that fetch will go away when compatibility is no longer needed or desired.

--Mark

> p.
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

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

On 23-06-11 16:25, Phil Blundell wrote:
> On Thu, 2011-06-23 at 13:36 +0200, Holger Freyther wrote:
>> On 06/23/2011 01:21 PM, Phil Blundell wrote:
>>> On Thu, 2011-06-23 at 13:18 +0200, Holger Freyther wrote:
>>>> -        destdir = os.path.join(destdir, "git/")
>>>> +        destsuffix = ud.parm.get("destsuffix", "git/")
>>>> +        print destsuffix
>>>> +        destdir = os.path.join(destdir, destsuffix)
>>>
>>> I think that "print" might be extraneous, but other than this your patch
>>> looks awesome.  I think this would resolve the problem that I was having
>>> in.
>>
>> great, yeah the print is bogus and the question if and how this applies to
>> fetch/git.py is also unresolved (i had a quick look but have not found the
>> dirname it uses to create the tarball).
> 
> I'm not entirely clear on what's going on with fetch vs fetch2 at all,
> in terms of whether fetch is going away at some point or the two of them
> are meant to be existing in parallel.  Can one of the TSC überhackers
> shed any light on what the intent is there?

Fetch2 is being used in OE-core, fetch is there for "old-style" OE like
.dev and 2011.03-maintenance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOA0+0MkyGM64RGpERAsmAAJ9D/PrqNupsL/pIF6ClrD39r+RZhQCgpbM+
Rj2c9UxKldqANJJiua4rRNA=
=xv3k
-----END PGP SIGNATURE-----