SRCREV and git packages
zecke at openmoko.org
Wed Jun 4 19:06:47 CEST 2008
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.
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.
> 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
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.
More information about the distro-devel