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

[Toshio Kuratomi]

Mattias Ellert wrote:
> 20 apr 2009 kl. 14.58 skrev Toshio Kuratomi:
> 
>> Mattias Ellert wrote:
>>
>>> Here is a description of the problem at hand:
>>>
>>> When upstream distributes sources in a gigantic installer containing the
>>> sources for 300+ packages it doesn't make sense to include this full
>>> tarfile for each SRPM, since less than 1% of it is used to compile each
>>> package. Instead the relevant subdirectory is extracted from this beast
>>> (properly documented in the specfile in accordance to the packaging
>>> guidelines).
>>>
>>
>> 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? :-(

I think that you're pretty clearly in violation of this guideline:
  https://fedoraproject.org/wiki/Packaging/SourceURL#Referencing_Source

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.

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.

3) Ask the packaging Committee for an exception to the Source Rule so
you can modify the source tarball as you're doing now.

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.

For the case of packages and subpackages that Orcan speaks of, when a
Requires between a subpackage and another package built from the same
RPM exists, we don't need to include the license file in both binary
packages.  When there is not a Requires, we still have a relationship
among packages via the SRPM and we could use a -common subpackage or a
main package (which is the most common usage) that has the licenses.
The FPC touched briefly on this when discussing Duplicate Files::
    https://fedoraproject.org/wiki/Packaging:Minutes/20090217#t12:18

As yet, no one has brought to our attention a specific, real life
package to work on as a corner case yet.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20090420/a18d7498/attachment.sig>