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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2008-07-12 at 22:09 +0200, Michael Schwendt wrote:
> On Sat, 12 Jul 2008 15:31:07 -0400, Doug Ledford wrote:
> 
> > First, before I respond to the rest of this, keep in mind that the
> > "overwhelming majority" of packages needs to be quantified.
> > Furthermore, at least one very significant package (the kernel) does not
> > massage files at all between SCM tag and tarball.  And to be honest, I
> > would be very surprised to find many projects that do have any
> > significant difference between a tagged release in the SCM of their
> > choice and their tarballs.  So I would like some examples please, which
> > shouldn't be hard to come up with since it is the "overwhelming
> > majority" of projects that obviously think when they tag something in
> > their SCM it doesn't need to match the tarball they make with the same
> > tag version...
> 
> Audacity is one example. They even include stuff in their cvs which would
> be illegal for Fedora to distribute.

Fair enough.  That's one.  And I'm sure that of the audio/video players,
there will be a number that have unshipable stuff in their CVS or
whatever repos.  So in our clone of the upstream repo we would remove
that stuff and go from there.

>  On the contrary, their tarballs are
> customised and stripped down to whatever they choose to ship.

Presumably one could replicate this as needed.  However, there is the
question of whether or not it's needed.  Remember that the concept using
an upstream tarball as the canonical source version that we represent to
the world that we are using is nothing more than a policy decision.
Nothing in the GPL or anything else said we had to do that, it was just
what we *chose* to do (long, long ago, in a galaxy far, far away).  It
is just as legitimate to say we are going to use tagged checkouts from
their SCM (or clones if they have a distributed SCM) and provide a means
of verification that we have done so.  It's all just policy, and we are
free to set policy as we see fit within the guidelines of meeting our
obligations under the GPL.

>  For other
> projects one cannot build from a scm checkout without running scripts,
> such as autogen.sh where one would need to reproduce the upstream
> development env.

Where is the reference on that BTW.  There was a time in the past when
someone asked me what they should do before generating their tarballs
and I told them to just tar it up and go, and I had every intention of
running autogen.sh myself during the build process.  Then someone told
me "No, they need to run autogen.sh before they make the tarball".  So,
why is that?  Why shouldn't the sources be autogen'ed against our
specific dev environment, after all we will be the ones building our
rpms in our build environment, so it would seem to make sense to me.
Obviously I must be missing something of great importance...

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

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

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux