All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Balister <philip@balister.org>
To: openembedded-devel@openembedded.org
Subject: Re: versioning madness
Date: Mon, 09 Apr 2007 21:23:06 -0400	[thread overview]
Message-ID: <461AE6FA.8010009@balister.org> (raw)
In-Reply-To: <461AE55E.6020301@openhardware.net>

[-- Attachment #1: Type: text/plain, Size: 3675 bytes --]

Tom,

Have you looked at bb collections?

http://bitbake.berlios.de/manual/ch04s02.html#id870544

I think they will do what you want. You can keep separate data and chose 
which data takes priority in case of duplicate packages.

Philip

Tom Walsh wrote:
> Cliff Brake wrote:
>> On 4/9/07, Tom Walsh <tom@openhardware.net> wrote:
>>   
>>> Tom Walsh wrote:
>>>     
>>>> AH!  You know, I use svn regularly and I didn't even think about using
>>>> it against the OE tree!  Thanks, that would be the best solution for me.
>>>>
>>>>
>>>>       
>>> Nope, didn't work as well as I had hoped.  Both monotone and subversion
>>> bit^H^H^H complain about having an existing directory, so, I cannot
>>> "overlay" into the OE tree with either.
>>>
>>> I'll just have to do it the old-fashioned way and edit the stuff with vi.
>>>     
>> I don't understand?  I have two trees that are completely separate
>> from each other:
>>
>> openembedded (HEAD of OE managed with monotone)
>> openembedded.custom (custom stuff managed with SVN)
>>
>> The beauty of this setup is the trees do not interfere with each other.
>>
>>   
> True, I was doing it that way, having two source trees.  That works fine 
> if your recipes are for something that is not already in the OE tree.  
> However, it becomes problematic where you have the same recipe in both 
> trees.
> 
> For example, sysvinit.  I have changes to sysvinit that I want to make.  
> So, you can do that only one of two ways:
> 
> 1. create a subdir under the OE tree as 
> '$projroot/org.openembedded.dev/packages/sysvinit/sysvinit/zipit', where 
> 'zipit' is the name of my MACHINE.  Copy initab into the 'zipit' dir, 
> then edit your changes.  Done.
> 
> 2. duplicate the recipe for sysvinit into the private tree 
> ($projroot/zipitbbfiles/sysvinit).  Do the same here with creating the 
> new MACHINE dir ($projroot/zipitbbfiles/sysvinit/sysvinit/zipit/), copy 
> & edit inittab as before.
> 
> When the two recipe trees are specified within 
> $projdir/build/conf/local.conf as BBFILES := 
> "$projdir/zipitbbfiles/*/*.bb 
> $projdir/org.openembedded.dev/packages/*/*.bb", still no problem.
> 
> The problem comes up later when someone edits the recipe for 
> $projroot/org.openembedded.dev/packages/sysvinit/sysvinit_2.86.bb and 
> changes the PR = "rX" to a value larger than the one contained inside 
> $projdir/zipitbbfiles/sysvinit_2.86.bb.  Guess what happens now?  The 
> undesired recipe now takes precedence over the private recipe copy as PR 
> gets asserted in the numerical version vote!
> 
> Do you see the problems? 
> 
> A) The problem is that my recipe would be outvoted in the second case 
> structure of a private tree having a duplicate recipe.
> 
> B) There appears no convenient way to manage the addition of an 
> extension to a recipe that is kept inside the OE tree (without commiting 
> that into the main OE repository).  That is the problem with the first 
> case example.
> 
> 
> I guess that the issue(s) are not so much "versioning" but "source 
> control" as the PV version voting borks private copies.  And, a code 
> versioning system like subversion (or another copy of monotone, perhaps) 
> is unable to do source control within the org.openembedded.dev OE main 
> tree copy.
> 
> That's what I would like to resolve.  I could commit my board changes 
> into the OE repository, but, as it is a proprietary hardware design, I 
> doubt that anyone would encounter one as surplus.
> 
> There are some more issues, but, I'll stop here.  heh.
> 
> Regards,
> 
> TomW
> 
> 
>> Cliff
>>
>>   
> 
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

  reply	other threads:[~2007-04-10  1:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-02 19:23 versioning madness Tom Walsh
2007-04-03 10:01 ` Marcin Juszkiewicz
2007-04-05 13:28 ` Cliff Brake
2007-04-08 17:10   ` Leon Woestenberg
2007-04-08 22:55     ` Tom Walsh
2007-04-09 16:51       ` Tom Walsh
2007-04-09 18:38         ` Cliff Brake
2007-04-10  1:16           ` Tom Walsh
2007-04-10  1:23             ` Philip Balister [this message]
2007-04-11  9:41               ` Tom Walsh
2007-04-11  9:57                 ` Leon Woestenberg
2007-04-10 13:54             ` Cliff Brake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=461AE6FA.8010009@balister.org \
    --to=philip@balister.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.