-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/23/2009 11:13 AM, Tziporet Koren wrote: > Alexander Schmidt wrote: >> Hi all, >> >> some time ago a new model for providing code updates in userspace >> libraries >> was decided upon for OFED-1.5. In this model, the distributors of >> userspace >> libraries should upload release tarballs to directories on the ofed >> server and >> new code should be picked up from there. >> >> I haven't heard any news on this topic since OFED-1.5 development has >> been >> started and we have new code for the ehca library pending, so my >> question is: >> is this new process already established or should we continue with >> sending out >> git pull requests? I think the distributors were in favor of the new >> model, so >> maybe they have an opinion on this?
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. > We have not defined it yet since the decision was to first have feature > freeze & alpha release and doing this change for the beta. > > tziporet > > _______________________________________________ > ewg mailing list > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg - -- Doug Ledford <[email protected]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpFLm8ACgkQQ9aEs6Ims9g73wCgiydabK8voDjG4jJKK+gMErEE aRQAoNr0Fl4ZetWYzYT4nri00BavXbFQ =wRhZ -----END PGP SIGNATURE----- _______________________________________________ ewg mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
