Doug Ledford wrote:
Yes, I certainly have an opinion ;-) My issue is not so much with
tarballs versus git pulls as it is well defined releases.
If you read the various git how-to documents on the web, one of the
common "best practices" (ok, really it's more like "if you don't do this
you are a putz" things) is that once a public git repo has a tag, that
tag should never change. So, if you have a git repo for, say, mstflint,
and you make a release of mstflint and tag it in the repo as version
1.4, then that tag, and the corresponding git tree associated with that
tag, and therefore the tarball created when you git export to tarball
from that tag, should *NEVER* change. If you add some fixes later, you
should *NEVER* respin the tarball from HEAD instead of the release tag.
If you want to respin a new tarball, you need a new release tag and
correspondingly a new version on the tarball.
So, how does one handle this when using git repos and wanting to pull
from head in order to get the latest fixes without going through a full
release cycle all the time? There are two ways to do this (speaking
specifically of creating src rpms).
One is to create a new tarball from head, but don't name it
mstflint-1.4.tar.gz, name it mstflint-1.4-git-<short_commit_ref>.tar.gz
then create your src rpm with a n-v-r as such:
Name: mstflint
Version: 1.4
Release: 0.<incrementing_number>.git<short_commit_ref>
Every time you spin a new tarball, you replace the short_commit_ref with
the short reference to the head you spun from. Also, every time you
spin a new tarball, you increase the incrementing number. The point of
the incrementing number is that it ensures that when rpm tries to sort
the old package versus the new package, it will always sort the new one
as being newer and perform an upgrade without needing the force flag.
If you didn't have that there, then the git short commit ref would
randomly sort as being newer or older depending on the specific commit
refs. It's also common to use the date instead of the short commit ref,
but it's not as precise in case someone wants to duplicate your tarball
by exporting from a copy of your git repo. I should note here that the
0.<incrementing_number> method is usually used when doing prerelease git
src rpms. This is so once the 1.4 release goes final, you can create a
src rpm that is just 1.4-1 and it will sort as being newer than all the
various git releases that you did. If, instead, you are doing
post-release git tarballs, where the tarball is version + patches, then
you can actually shorten the src rpm n-v-r to just use Release:
<incrementing_number> and only reference the short commit ref in the
name of the tarball.
The second option (and is what we do internally with our kernel rpms
since they are stored and worked on in git, then exported to rpm format
for builds) is to pick a tag as a starting point. So, in this example,
we would start from the official mstflint-1.4 tag and we would export an
mstflint-1.4.tar.gz archive. Then, in order to pull in all the
additional fix patches, we have a script that gets the commit ref for
the tag of our tarball, then basically does a git format-patch
<tag_commit>.. so that we get all the patches from the tag to HEAD. The
script then uses an rpm spec file template and inserts appropriate patch
lines in the spec file for all those patches. In our case we hand
modify the version in the spec file for each official build, which is
why our 2.6.18 kernel is up to release version 155+. This option has
the advantage of making it easy to tell exactly what patches have been
applied since the official release without having to inspect the git repo.
Regardless, the point of all this is that when someone downloads the
OFED-1.5-nightly tarball and unpacks it, then looks in the SRPMS
directory, they should be able to tell, just by looking at the n-v-r of
any given package, if it has changed from the previous OFED-1.5-nightly
tarball, and the version-release combination of any given package should
always sort in ascending order so that the newer package will be seen by
rpm as an upgrade from the previous package.
This is a good method and we will adopt it.
Tziporet
_______________________________________________
ewg mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
