Hi,
Good to hear from you! :)
I just had a quick chat with Holger on irc about this. My views are
below, Holger may or may not want to add to them...
On Thu, 2007-03-08 at 09:02 +0100, Henryk Plötz wrote:
> 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 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.
> 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.
I'm thinking this can be done without actually having to change OE
itself too much, just bitbake really needs improvement. I'll elaborate
below.
> 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)
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)
> 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.
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.
> 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.
I think the fetchers need to determine if the source changed and then
change SRCDATE in some way that makes sense to the SCM concerned. If we
can't generate a unique, incremental number (like for git), we need to
emulate something, at least for local use.
Does any of the above help/seem reasonable?
Cheers,
Richard
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev
