Moin, I'm currently working with the openmoko project (http://www.openmoko.org) who are using openembedded and thus bitbake for a linux based phone and I'm helping them with changes to bitbake for improved handling of svn/git/cvs fetching in combination with SRCDATE=now. The current bitbake version in use is 1.6.6.
The problem, in short, is that they have some recipes which should closely track the upstream progress and bugfixes and thus use SRCDATE=now. However, this creates packages with name-versions like uboot-gta01-1.2.0+svnnow-r2. This is not particularly useful on a rebuild, since bitbake will see that it already built that package in the "svnnow" version and will never build it again and thus not pick up any upstream changes. The first solution was to include, on each build, the current date/time into the version number which at least fixes the "won't get any updates" problem. Instead it introduces another problem: all those packages are rebuilt every time a build is started, because the date and time have changed. I have now code to instead fetch the remote revisions and include them in the package revision numbers (e.g. I augment PR with the information that I fetched). For example for a package which pulls from git and svn I generate uboot-gta01-1.2.0+svnnow-r2_0_1229 where 1229 is the remote "Last Changed Rev" parsed from `svn info URL` (and 0 indicates that I have not yet written revision fetching code for git). My preliminary patch against 1.6.6, based on code from Harald Welte, is here: http://people.openmoko.org/henryk/bitbake-1.6.6-om2.patch to be used with a modified base.bbclass from here: https://svn.openmoko.org/trunk/oe/classes/base.bbclass The idea is that every fetcher should be able to somehow query the remote repository on which revision identifiers are current and then return this information (as a list of strings, for maximum extendability). bb.fetch has a new method compute_revisions() which queries the revision information for all urls and returns a concatenated list. base.bbclass then takes this list and appends it ("_".join()ed) to PR. Any feedback and ideas for improvement are welcome as this (or something like this) should some day find its way back into upstream bitbake. As for the individual fetchers: SVN was easy. I'm not yet sure about CVS and GIT. For GIT at least it's easy to get the remote tag (e.g. basically a SHA-1 over the current revision) but these can't be compared for bigger than/less than. I'm thinking about two plans here: + use the date of the last change (pro: would apply to SVN and CVS, too; con: might be flaky and not reliable) + somehow count the number of commits (maybe from some base revision on) (con: i see no easy way of getting this information and might even need to check out the whole repository) I think it might be worthwile (or even necessary) to make structural changes/additions to the general concept of versions in bitbake to explicitly add support for stating information about the source version. Non-integer revisions aren't currently handled at all if I see that correctly? Input on this would be highly appreciated. Or maybe a correct solution would look entirely different with some changes in other parts of bitbake: (rough idea, not sure how to implement) let the fetchers determine whether the sources changed, independently from the version/revision number and then include the build date into the package version. This is not nearly as nice as having a proper source revision number in the package version but at least would be universally applicable. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
