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

[Doug Ledford]

On Fri, 2008-07-11 at 14:08 -0800, Jeff Spaleta wrote:
> 2008/7/11 Toshio Kuratomi <a.badger at gmail.com>:
> > Seriously, making use of this kind of functionality is a huge change in the
> > expectations we have for what a source package is.  Seeing as jcollie and I
> > weren't able to sell people on making our SCM hold exploded trees of the
> > source from tarballs, I think that having rpms that are created from SCM
> > checkouts without the tarball intermediary are likely to meet with a lot of
> > resistance.
> 
> We pass on a significant burden with regard to source distribution, to
> anyone re-distributing Fedora media or install images. I'd like to
> make sure that I understand how rpms created from SCM check-outs
> impact our ability and downstream distributor's ability to meet that
> burden.

You merely need to be able to check out the source.  In our case, that
means we make a publicly available server for the scm repo and the gpl
software recipient can check out the specific version used to build a
specific package from us.

If you redistribute what we ship, then you need to be able to provide
the same thing to your downstream customers, so you need your own scm
repo server.  Now, for hg and git, this is easy.  You simply clone our
repo on your server and make your clone of our repo available to the
world.  Done.  For subversion, I *think* you can do this too in the
sense that I think when you check out a subversion repo, you actually
get all the versions of the code and the entire repo is mirrored
locally.  For CVS, this is a nightmare.  It's best just to not use CVS
as a repo source because you either have to have the downstream party
checkout each update to CVS and import it into their own CVS tree, or
you let them rsync the CVS server's repo, in which case they can't make
any changes of their own.  It's just not pretty.  It's why CVS should
just frikkin' die already.

>   If we aren't doing something to cache a copy of the
> corresponding source that acts like our current look aside cache,

The repo itself acts as the look aside cache.  In order for that to
work, tags must be immutable and code can not be removed.  However, this
is no different than us not being able to rm tarballs from the cache
that we have shipped, nor how we are not allowed to unpack a tarball,
change the contents and then repack it back up and put it back on the
cache under the same name.  Exact same policies, different
implementations.

>  I
> would need someone to explain to me how this sort of thing impacts the
> ability of a downstream distributor to meet the source distribution
> requirements... using extremely small words.

Don't use CVS (and maybe not subversion, I just don't know subversion
enough to answer that), use a policy of immutable tags and commits on
our own private branches enforced by access controls on our official
repo server, allow downstream to pull from our repos into theirs,
problem solved, and only a few large words.

-- 
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: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080711/83c71c19/attachment.sig>