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.
