SRCREV and git packages
andy at openmoko.com
Wed Jun 4 21:51:47 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
|> 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
| time in creating and maintaining and is pleasing the people that want
| the latest versions and the ones creating a stable locked down version
| by all means scratch your itch and do something about it. But stating
| facts is not the way I appreciate scratching an itch.
Actually I have made my own distro based on cross RPM singlehanded in
the past for my projects, with some quite complex stuff in it like
postfix, dovecot, openssl and so on. It didn't "please" anybody but me,
but I did do it. So unfortunately this gives me an RPM-centric baseline
that I know very well to compare the OM / OE dev offering to.
|> 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
Not flat tarballs, source packages. If you look inside a source RPM you
find an upstream dist-tarball and any number of discrete patches which
are applied by the spec file at build time. (hundreds in the past on
Fedora kernels for example). If you look at our kernel tree we could
certainly handle our git patchset in a source package as a patchset,
more sustainable would be making a tarball from the last release tag and
then the rest as a patchset.
| history in the repository the way you want. But you didn't progress at
| One will write scripts that will create more recent tarballs for you,
| wanting to always build the latest will love you too for manually
| source packages first. The admins will love you too because they want
| their storage for archiving all the tarballs ever created, for every
| revision (webkit is hundreds of mb...).
All I can say is, tell it to Redhat. RHEL and Fedora are obviously much
older and larger than OE / OM in every metric, but their distros ARE far
more widely loved and used. They use the methodology I describe and if
a newbie dev needs to build against their packages, he googles a bit and
then is compiling in ten minutes, even if it links to other libs. If he
googles some more and meddles for an hour or two his first app is
packaged. That is not what we got here.
| Regarding rebasing. The next time you invoke git-gc the version will
| 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
| tarball contained.
Source packages do not have this problem since they are not flat
tarballs. In fact, nothing stops you choosing to manage the patchset
inside the source package by putting an attenuated ./.git into the
| By means of thinking in black and white you are certainly right that
| tarballs on the infite turing tape is going to solve the issue.
| In the world of compromises and people wanting to always build the
| people wanting to create a stable product such black and white
| not helpful.
I never understood why you have a centralized build host, pretty good
example of monolithic black and white thinking if you ask me. If people
want the latest Qtopia that's changing five times a day, shouldn't it be
that the folks working on Qtopia - and building it locally already -
build it and put binary packages up somewhere, while the official repo
has a slower, more stable approach and is not involved in the white-hot
development madness? What is wrong with decentralized and distributed
build that package signing doesn't resolve? It'd certainly simplify
| 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
| 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.
No, I agree that is a normal and good way, and by keeping stuff in
"andy" branch for a while it should be OK the bulk of the time without
reverts. It was just curious to hear the reason and that the build
system takes such close note of the patchset.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the distro-devel