Yury, you have missed the point, as many before you. CentOS has no interest in tracking SRPMS since the are **not** changing them. All they want to do is to repack them and comply with rules of repackaging them, which include de-branding them, etc... What you do not have to change, you do not need to track... If upstream would be nice/stupid enough to solve all issues with properly solving dependencies, everybody could just run them through recompiling and there would be no need for all of this hassle. Since upstream needs (more) time between their release and downstream rebuilds, in order to make better profit in the mean time, they have made problems harder for rebuilding crews. For me, it's that simple. And I do not hold grudge on upstream, their choice makes them profitable enough to be able to invest in development of the product we use and pay not with our money but with our nerves. Those who cherish their nerves more then money will buy upstreams product, and the rest of our self will loose nerves and keep our money. Ljubomir. Yury V. Zaytsev wrote: > 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. >