SRCREV and git packages

[Holger Freyther]

On Tuesday 03 June 2008 22:29:35 Werner Almesberger wrote:
> Holger Freyther wrote:
> > You will need a local repository for every piece of git software we use,
> > even if you don't use it at all. E.g. three disjunct kernel trees wasting
> > some harddisk space.
>
> Hmm, why ? What is the operation that actually requires you to compare
> versions ?

Let me explain how bitbake is working. If someone says "bitbake foo" it will 
parse the configuration (conf/bitbake.conf) and then look at each file 
mentioned by the BBFILES glob. The following information get extracted on the 
initial parsing. Package Name (PN), Package Version (PV), Package Revision 
(PR) and what this package provies (PROVIDES defaulting to PN). The PV-PR 
gets used to determine which file to build (either by using the highest 
version or PREFERRED_VERSION).

With building stuff from git, you somehow want to have the revision/number 
inside the package version/revision. You want this because of being able to 
upgrade to newer versions.

To be able to upgrade you need to have increasing version numbers. With 
subversion this is trivial, with a hash (as provided by git) this not 
trivial. A more recent kernel might have a hash that is smaller than the 
month old one.

And this is bringing us to the question. The only sane way to get an 
increasing number for a hash based system is git-rev-list | wc -l and use 
that result (assuming no one is rebasing and removing commits). Now 
git-rev-list is requiring a local repository (I checked the source there is 
no easy way to solve that), this means unless you BBMASK out things you don't 
want to have you will git-clone the source. This behaviour is not enabled by 
default due this but "required" for our autobuilder as it will create git 
based packages that can be upgraded.


z.