On 07/31/2009 01:01 PM, Josh Boyer wrote: > On Sat, Aug 01, 2009 at 01:20:12AM +0530, Rahul Sundaram wrote: >> On 08/01/2009 01:14 AM, Jesse Keating wrote: >>> On Sat, 2009-08-01 at 00:58 +0530, Rahul Sundaram wrote: >>>> >>>> I don't think anybody is going to argue that extracting source from srpm >>>> or pulling tarball + patches from our package cvs is ideal. So I don't >>>> see why we should continue have a lame exception. >>> >>> Yeah, it's not idea. They should just pull it from our upstream source >>> repo by the tag we apply when we make the release we package. Then >>> they're much better setup to provide patches back to us in a preferred >>> manner. >>> >>> Lets start moving beyond the tarball crap. Where this exception comes into play, there is no upstream source repo. >> >> That's kind of side tracking though. Point is that SRPM as upstream >> source is simply a stupid thing. We would complain loudly or atleast >> whine about it if Novell or Mandriva or Debian did that. Wouldn't we? >> >> Why should we have an exception anymore? I can't think of a single >> reason why we should. > > Because doing this: > > Source0: http://cvs.fedoraproject.org/lookaside/pkgs/anaconda/anaconda-11.5.0.59.tar.bz2/0b0b7b30f1ff03bad05bda3d052b73a8/anaconda-11.5.0.59.tar.bz2 > With the exception removed, this would violate the letter of the guidelines for new reviews but might actually be acceptable. It is better than:: Source0: 12345.tar.gz because people can browse to:: http://cvs.fedoraproject.org/lookaside/pkgs/anaconda/ and check for new anaconda packages. The reason it might violate the letter of the guidelines without the exception is that the Guidelines are designed to confirm the package comes from upstream during the review so the reviewer needs to be able to get it from somewhere and check it against what's in the SRPM. Since we are upstream, that might not matter. > is really no better. All you are doing is forcing people to list a URL. This is not what removing the exception is about. > Also, > if an upstream project doesn't want to host all that and wants to use the SRPM > as the source, who is Fedora to tell them they can't? > We do for every project except those developed from within Fedora (which, in practice, seems to mean Red Hat developed software). So it's a Fedora/Red Hat development practice that would be changing. The proposal is to remove an exception from the Packaging Guidelines. Here's the text of the exception: """ We are Upstream For some packages where we are the upstream authors, for instance, the system-config-* tools, the source rpm that we distribute is the canonical source of the files. There is no public revision control system or publically released tarball for these programs so there is no tarball to list. Add a comment like the following to the spec: # This is a Red Hat maintained package which is specific to # our distribution. Thus the source is only available from # within this srpm. Source0: system-config-foo-1.0.tar.gz """ This has nothing to do with whether upstream releases tarballs or not. It just has to do with whether upstream source is available from anywhere but our srpms and lookaside. If FESCo decides not to remove the exception, it probably makes sense for FPC to update it to use the lookaside URL as that seems to be a better implementation than simply telling people to download the SRPMS. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
