Heads-up: brand new RPM version about to hit rawhide

[Doug Ledford]

On Mon, 2008-07-14 at 17:19 +0000, Kevin Kofler wrote:
> Doug Ledford <dledford <at> redhat.com> writes:
> > The magic words above were "(or get them packaged)".  Our separate SCM
> > setup really just means they don't want to futz with it.  However, if
> > the process for an upstream developer was more like:
> > 
> > Develop in their own SCM, push SCM changes to (Fedora/Debian/SuSE
> > repos), kick off build process in (Fedora/Debian/SuSE), done.
> 
> They'd still have to update the specfile (or equivalent, e.g. the debian/ 
> directory) for the individual distribution.

It takes less than you think for this.  We now have opensm in fedora
CVS.  Pull that package, then do make prep, then go look at their
scripts directory.  I don't *use* what's in there, because I have my own
versions, but they are already set up to deal with the differences
between Red Hat and SuSE RPMs in that directory and in their spec file.
So, for them, it *would* be a push, build operation.  Of course, that's
assuming we let their spec file through review...I don't use that
either.

>  Uploading the tarball isn't the 
> hard part of packaging, it can even be scripted (and I also don't see how it 
> would be any easier to push the SCM changes than to upload the release 
> tarball),

I think you'd be amazed at just how hard it was to get the Infiniband
community doing *any* tarballs.  Even today, out of the 26 packages they
produce, only about 12 have tarballs available.  The rest are git repos
only.

Of course, I'm not saying they are common...most of them were new to
open source development as of about 3 or 4 years ago.  They didn't cut
their open source teeth on tarballs.  First it was subversion, then git.
But, I think it's fair to say that as times change and progress, this
lack of familiarity with tarballs and tarball releases will probably
only grow as various dscms become more popular and easier to use.  But,
that's just my own personal crystal ball speaking, I could be wrong.

>  updating the specfiles is.

For lots of packages, this can be a write once and forget operation for
the most part, only needing a changelog/version update per build, which
can also be scripted.  Again, look in the opensm prep sources, I believe
they still make a makefile entry that updates the opensm.spec.in and
spits out the correct opensm.spec.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080714/1fd32477/attachment.bin