SRCREV and git packages

[Holger Freyther]

On Wednesday 04 June 2008 16:52:52 Andy Green wrote:
> Somebody in the thread at some point said:
> | Holger Freyther wrote:
> |> 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.
> |
> | Yup, I understand that. But, assuming you've already installed package
> | foo, version X, then the question in your example is "is there a more
> | recent version of foo than version X".
>
> Isn't this an issue because only we don't generate source packages, you
> need a magic tag to go to in the scm to recover the sources
> corresponding to the binary package?

Hey Andy,

this is getting really boring. You have made your point, cope with that. I 
don't tell you how you should do your work either. The "lack" of a source 
package (we can just generate them fine and store it on the infinite tape you 
provide me with) is not in anyway related to this issue....

How is "should we build a new package" and "should we create a new source 
package" a different problem? It looks the same to me.

> If you did build source packages, you could forget this issue and
> maintain an incrementing "release" index number that is per build host,

Please reread this thread and John's mail. It is not about a per build 
host "release" index (we have had that for ages), it is about a per 
repository index. And the only way for git I'm aware of is git-rev-list | 
wc -l in a local repository.


> and a package tag identifying the build group.  There is the solution
> for detecting newer packages... and it seems the built host -scope
> incrementing number is already an established practice anyway with this
> r<number> in the package names if I understood it.

it might be the weather but upgrading a package in an image != building a new 
image.

z.