On Fri, 2011-03-11 at 03:55 -0600, an unknown sender wrote: > Now, upstream releases a new package ... what do you do? Lets import it > into our SCM. Hmmm ... it overwrites the spec file and removes my > changes ... that's OK, I can still see them from commit 1, so I will go > back and grab them from there and reapply them into the new spec file. > But now, that makes the versions complicated and bringing in the new > spec shows me what upstream changed, but it does not show me anything > more about my changes than the first one did. During the build process, > I need to add another patch and specfile change and make a commit. Now, > I have 4 changes to the spec file ... which ones are mine and which ones > are upstream? After about 3 or 4 cycles it is all muddled. However, if > I grab any version of the upstream package and the corresponding centos > version of the package and diff the SPEC and SOURCES directory of those > it tells me in an instant exactly what is different from upstream. So, > for the SPECs it is MUCH easier to get the info you want to know (what > did CentOS roll in on package x-y-z.1) by using SRPMS than by using SCM. Hi Johnny! I don't want to get actively involved in this debate, particularly because my competences are somehow limited, however I thought it could be valuable for you to know that Debian and its derivatives have exactly the same problem. To solve it, they authored a toolset that wraps around the package building facilities (pbuilder is the mock of Debian, debuild is equivalent to rpmbuild etc.) and different kinds of SCM. There are several concurrently used sets of tools, for each SCM of choice, most notably git-buildpackage, hg-buildpackage, svn-buildpackage etc. The point here is to solve exactly the problem that you are discussing. They automatically create tracking branches on top of upstream imports (upstream could be the original author of the program, or a packaged version of the program e.g. from Debian that is considered to be "upstream" by a derivative, i.e. Ubuntu) that let you re-base your older changes on top of newer upstream changes, tag the uploads you do to the archive, combine all patches in one pack of patches, concurrently work with several branches for different distributions (backports), auto-generate changelogs and much more. At the same time, the immutability of the original upstream tarballs is guaranteed by a tool called "pristine-tar" and validated by computing a hash. That is to say, that this problem has been solved rather efficiently for Debian and allows for a very enjoyable packaging workflow using your favorite tools to manage the history. It could be that there are similar efforts for RPM-based distributions, but I am not up to date with that. It's rather a proof of concept. > The SRPMS themselves are BETTER tracking devices than an SCM. Provided a right set of tools, they are definitively not, as are not "source debs". It could be that these tools do not exist for RPM based distributions and if indeed they don't, CentOS might not be the right project to develop them, but just thought I would mention that. To me this point is of an academic interest. -- Sincerely yours, Yury V. Zaytsev