mån 2009-04-20 klockan 14:57 -0700 skrev Toshio Kuratomi: > Mattias Ellert wrote: > > 20 apr 2009 kl. 14.58 skrev Toshio Kuratomi: > >> > >> What's the bugzilla URL? I think people have answered the licence > >> question pretty well but I'm curious to see how the split up of the 300+ > >> packages is being accomplished. That seems like it would be a more > >> contentious area. > >> > >> -Toshio > > > > > > Here is the reviewer saying "Will not approve package unless license > > file is removed": > > https://bugzilla.redhat.com/show_bug.cgi?id=467235 > > > > Here is the reviewer saying "Will not approve package unless license > > file is added": > > https://bugzilla.redhat.com/show_bug.cgi?id=478917 > > > > The specfiles for the two packages are almost identical. > > > > The split of the huge upstream installer was not an issue with either > > reviewer, except one of them requested it should be better documented - > > after implementing that he was happy. > > > Ugh, upstream does put you in a bit of a bind, don't they? :-( Thank you for pointing out the obvious. > I think that you're pretty clearly in violation of this guideline: > https://fedoraproject.org/wiki/Packaging/SourceURL#Referencing_Source I don't see the violation here. The page clearly states what you have to do if upstream does not provide the source tarball for your package. The recipe is to state the commands needed to reproduce the tarball from what is provided by upstream, which is exactly what is done in this case. Quoting the guideline verbatim: "There are several cases where upstream is not providing the source to you in an upstream tarball. In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX." After which follows a few examples. There is no substantial difference between the example stated on the page: # The source for this package was pulled from upstream's vcs. Use the # following commands to generate the tarball: # svn export -r 250 http://www.example.com/svn/foo/trunk foo-20070221 # tar -czvf foo-20070221.tar.gz foo-20070221 Source0: foo-20070221.tar.gz and the description in for extracting the source in this case: # Source is extracted from the globus toolkit installer: # wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2 # tar -jxf gt4.2.1-all-source-installer.tar.bz2 # mv gt4.2.1-all-source-installer/source-trees/core/source globus_core-5.15 # tar -zcf globus_core-5.15.tar.gz globus_core-5.15 Source: %{_name}-%{version}.tar.gz So the way the source is extracted and how it is documented is within the existing guidelines. Three different reviewers have already approved packages where the source has been created and documented in this way. > Have you asked upstream whether they'd consider releasing individual > tarballs for all components? Since they release individual update > tarballs, this might be an oversight rather than something that they > don't want to do. This would be the ideal outcome for us. > > If they won't do this, there's a couple things you could do: > > 1) Package the monolithic tarball and remove the extraneous library > sources at buildtime. You'd put each component into a subpackage of the > main package (so far the same as any other package). When upstream > releases one of their update tarballs with just an individual component, > you'd include that as a separate Source. This won't work. Each package expects that the previous packages it depends on are already installed in the final location when it is built. The upstream installer script does: configure A, make A, make install A, configure B, make B, make install B, and so on. Besides, each package has a separate version number, and I haven't seen an SRPM building packages with different version numbers yet. And do you really want an SRPM building something like 600-800 binary packages? Apart from these technical objections, such a package would be almost unmaintainable. You are not the first one to suggest this, but it is really the wrong thing to do. > 2) Make separate packages each using the same tarball (unless an update > tarball was released with just that component). This doesn't take up > much more room on the server (since the huge tarball will have the same > name and md5sum) but it does make building locally a bit more painful. The lookaside cache http://cvs.fedoraproject.org/repo/pkgs/ is unfortunately split per package, so this will not save any space on the Fedora server. The really huge waste would of course be that this huge unused piece of code would be inside each SRPM and replicated to all Fedora mirrors wasting both bandwidth and disk space. So this is also not the right thing to do. > 3) Ask the packaging Committee for an exception to the Source Rule so > you can modify the source tarball as you're doing now. I fail to see where the exception is (see above). > As for the specific licensing case. When the packager is doing the > splitting of the tarball I think that Ralf's note that you may be > legally obligated to copy the license file into the new tarball carries > a lot of weight. If you have to keep splitting the tarball at the > packager level I'd amend the instructions for generating the Source0 > tarball to copy the license file from the upstream source in addition to > the module directory. To summarize this thread, I conclude that the majority thinks that the license file must be part of the package. I also conclude that rather than being made a separate source file (which is how it was originally implemented) the license file should be copied into and made part of the extracted source tarball. Is this a correct assessment of the view of the members of this list? > -Toshio Mattias
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
