[Fedora-packaging] Packaging of license file in case of extracted sources

[Mattias Ellert]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2272 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20090421/08b76446/attachment.bin