[oe] versioning madness

[Philip Balister]

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 at 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
>>
>>   
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070409/eb9416da/attachment-0002.bin>