versioning madness

[Tom Walsh <tom@openhardware.net>]

I would like to know how others are handling this problem.   As you 
already know, versioning can be "interesting" with OE.  It is probably 
how I have approached the issue of keeping my list of files seperate 
from the OE bb filetree.

In my project, I have a number of packages which needed specific changes 
to files so that they reflected the needs of the target.  A simple 
example is that of a list of /dev/devices.  initscripts controls the 
device creation through the device_table list.  So, I have a 
device_table file unique to my target.   No problem.

What is a problem is controlling the changes that I make to the OE 
packages tree.  If I simply create a ${MACHINE_NAME} directory under 
packages/initscripts/initscripts-1.0/, then I have to remember that it 
is there.  As this target may never be in the mainstream OE database, I 
keep the uniqueness of my changes in a seperate bb filetree.  The 
local.conf names the BBFILES location of both the mainstream OE tree and 
my bb tree.

This works, if I copy, in total, the packages/initscripts directory into 
my bb tree, then do the changes inside the copy.  I now know where my 
changes are and can distribute them without having people invasively 
patch the OE tree.  Where this breaks down is the in the "PR" variable 
(PR = "r88").  Bitbake will ignore my initscripts-1.0.bb totally, if the 
OE initscripts has a higher "PR" number than my local copy!

The solution that I have done was to set my copy of initscripts-1.0.bb 
to have a PR="r9999", this forces bitbake to always defer to my copy of 
the bb file and ignore the copy in the OE tree.

Develing further into this, as it would seem to me that while this is a 
solution, it is not "elegant" nor is it preferred.  When others make 
changes to packages, such as initscripts, these changes would not be 
propogated into onto my target.  With forcing bitbake to ONLY use my 
copy, changes are not propogated.

It would seem to me that something like this would work, but it doesn't:

BBFILES/initscripts/files/MACHINE_NAME/device_table (IOW: 
zipitbbfiles/initscripts/files/zipit/device_table  would override 
org.openembedded.dev/packages/initscripts-1.0/files/device_table)

That having named 'zipitbbfiles' in local.conf as part of BBFILES, and, 
naming the package 'initscripts' with a dir of 'files'.  That bitbake 
would logically flow with its search for 
'files/${MACHINE_NAME}/device_table' when choosing 'device_table' ???

You would think so, but it doesn't.  The presence of the secondary 
initscripts directory is ignored.  This may be how it should be as there 
is no overriding "PR" value to cause bitbake to vote-off the OE default 
copy.

Do you see what I am trying to do here?




So, the madness continues with this.  Ok, I'll try to use the 
PREFERRED_VERSION_initscripts = "1.0+zipit" and rename my copy of 
initscripts_1.0.bb to initscripts_1.0+zipit.bb.  That does work...  I 
don't need to edit the bb file and set PR="r9999" anymore.

However, this breaks down as well.  There are bb files inside the OE 
tree that do not have a version!  For example: 
org.openembedded.dev/packages/modutils/modutils-collateral.bb is not 
versioned.

Pulling my hair out at this point.  I have reverted back to PR="r9999" 
to force the bitbake version election.  It looks sloppy though, isn't 
there an easier, cleaner way to keep ${MACHINE_NAME} specific files in a 
seperate tree, or, am I resigned to patching the OE tree whenever I want 
to create a working database for my target?




The major issue, as I see it comes down to changes.  If I put my changes 
into the local copy of the OE tree, how do I archive those changes and 
pass them onto someone else?  I could gain write access to the OE tree, 
but, this target should not (or would not) ever be that widespread to 
require it to be added to the repository.

Otherwise, I will still have to set PR to a fantastic value and keep the 
bb files isolated, or use a tarball to patch whatever OE tree that 
someone installs onto their system?



Regards,

TomW





-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------