SRCREV and git packages

[Holger Freyther]

On Wednesday 04 June 2008 18:35:01 you wrote:

> Actually you do, but never mind.  Maybe it's boring for you because you
> didn't understand my point.

hehe, I highly appreciate your kernel, hardware work but this is really 
boring. If you think you can create a distribution that needs less amount of 
time in creating and maintaining and is pleasing the people that want to use 
the latest versions and the ones creating a stable locked down version then 
by all means scratch your itch and do something about it. But stating false 
facts is not the way I appreciate scratching an itch.

<war story>
At ROAD we only wanted to build from source that is available on our server 
with backup and archiving in place. So what we did was to change the various 
FETCHCOMMAND lines in bitbake.conf to /bin/false. So your build failed when 
you actually wanted to fetch from git, svn.... This forced us to make sure we 
put the sources somewhere before we could use it.
</war story>



> Doesn't this have ramifications for source capture, or is it about
> something else:  ''If we *build* a specific revision which gets
> "orphaned" (no one is referencing is) and people do a fresh
> checkout/clone they will not get this revision''?  If so, a source
> package a build time would indeed resolve it.  Right?

Well, like with everything this is not black and white. Sure we can stop 
building from any repository and only use tarballs. Then you can change the 
history in the repository the way you want. But you didn't progress at all. 
One will write scripts that will create more recent tarballs for you, people 
wanting to always build the latest will love you too for manually creating 
source packages first. The admins will love you too because they want to use 
their storage for archiving all the tarballs ever created, for every single 
revision (webkit is hundreds of mb...).

Regarding rebasing. The next time you invoke git-gc the version will be gone. 
Now you have a tarball and the license is obeyed but you lost all the 
benefits of a SCM, you can not use git-log to actually see which patches your 
tarball contained.

By means of thinking in black and white you are certainly right that putting 
tarballs on the infite turing tape is going to solve the issue.

In the world of compromises and people wanting to always build the latest and 
people wanting to create a stable product such black and white thinking is 
not helpful. And a linear history is something you have by default with 
cvs,svn,hg,mtn and even for git you need a --force to create a non-linear 
history and is disabled by default in the repository. So not using rebase on 
a public branch is common sense. If you think this is not possible 
for "stable" please respond to that mail and we can discuss this there.


z.