[CentOS-devel] Updates from today

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