Moin, Am Fri, 09 Mar 2007 00:37:03 +0000 schrieb Richard Purdie:
> My first concern is that we should really change the PV, not PR. PR > represents a particular bitbake recipe revision and you're changing > the underlying code which is PV. I see. One of the reasons for doing this was that I was striving for genericity especially with a look on how multiple fetchers would work together. For example uboot-gta01 is built with sources from git with additional patches from svn. This necessitates: a) either each fetcher needs to introduce its own revision identifier or b) all fetchers must use a compatible scheme with a well-defined max() function (e.g. date/time). In any case involving more than one revision identifier it is important that these are 'worth' less than the bitbake recipe version. E.g. suppose I took some fictional package with source from cvs and git today with its revision identifiers ["20070308052342", "eb92f613556800f7483666db09d9a237ad911d4a"] (this is the naive approach with the sha1 for the git revision identifier, just ignore that for now) and added some patches from an svn source. The resulting list of revision identifiers could look something like ["1229", "20070308052342", "eb92f613556800f7483666db09d9a237ad911d4a"] and this would be decidedly 'less than' the original list. However, since I changed the bitbake recipe I would also have been bumping the PR. If the source revision was 'worth' less than the PR, then everything would be ok. This could be avoided if we had compatible 'last changed' date/times for each of the URLs and then take the most recent of those. We can't get this information for all of the fetchers, and even if we could, it would not be reliable because it would be dependent on the correctness of remote clocks. And even if we ignore that, then these date/times are not compatible because they are dependent on _different_ remote clocks that may or may not be synchronized. I have an idea for a partial solution to this: instead of 'last changed' use 'last change detected'. Each fetcher would need to store some semi-permanent local metadata for each url it handles which should include the date/time that the last change was detected and some kind of data to determine when a change happens (kind of like HTTP ETag). For SVN this would be 'Last Changed Rev', for GIT this would be the SHA-1, and for CVS ... don't know, list of files and file revisions (or hash thereof) maybe. Pro: relatively reliable, generic, should apply to all version control systems Con: revision identifiers generated this way are not comparable between different developers This is especially of concern since openmoko wants to share the tarballs through CVS_TARBALL_STASH at http://downloads.openmoko.org/sources/ so that the generation of an interchangeable filename should be a separate problem. Having the git hash in the tarball name should be ok. > If we change SRCDATE, bitbake/OE magic means it will build a new > package since SRCDATE is in PF through PV. The problem then becomes a > question of what would be acceptable values for SRCDATE. As you > mentioned, each SCM presents a different problem. I'm thinking the > following when we're building a "now" package: > > > CVS: > > This has to use a date/time stamp since it has no concept of revisions > globally. I suggest the fetcher updates SRCDATE to the last time CVS > HEAD was changed. Instead of just being a date, it would be a full > timestamp. A new commit would mean a new date and hence a new build. > > Format x.y.z+cvs20060504030201 > (SRCDATE="20060504030201", PV = "x.y.z+cvs${SRCDATE}") > > > SVN: > > We should drop the dates for SVN and work to a revision. Any dates set > get converted into a revision. This would be a behaviour change but I > think its a sane one. Will need discussion and maybe a compatibility > mode. > > Format x.y.z+svn+r123 > (SRCDATE="+r123", PV = "x.y.z+svn${SRCDATE}") > > > GIT: > > Tricky. We could just put the tag into SRCDATE and that would > guarantee a rebuild but it would break package upgrades and hence > images. Instead I think we'll have to have a local revision sequence > number (with the tag stored against it). If the tag changes, SRCDATE > changes to the next number in sequence. This will work fine for > people's local builds. For anything ending up in a feed/release, > using a tagged release will be especially recommended. > > Format x.y.z+git+localr123 > (SRCDATE="+localr123", PV = "x.y.z+git${SRCDATE}", SRCDATE generated > from some local number cache in staging) As indicated above these are viable strategies when there is only one fetcher with only one source involved, but they don't cooperate well. For git specifically there's also the problem that these sequence numbers don't compare between developers. That's why I was suggesting a 'last change detected' date/time above. My intuition indicates that there might be an even better solution for git (that maybe even partially applies to cvs): If git won't give us a 'Last Changed Rev', just compute one. E.g. count the number of commits from either the origin or at least a defined (in the recipe) base commit on. (Changing the base commit should bump the recipe revision and everything would be ok again.) However, I'm not familiar with git and don't know if that's feasible (preferably without downloading the whole repository). > The problem is not just limited to bitbake. The package version fields > (PV-PR) need very careful handling since these are used in the > resulting packages and then the packages go into feeds and/or are > used to build images. The feed and image generation tools need to > have package version fields they can compare. Non-integer fields are > really just not an option. Right. Alternatively one might investigate into updating the tools. Or now that I think about it: Having the current date (at build time) in the version information of the generated package is just fine, as long as it's different from the information that is used to determine when to rebuild. -- 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
