Re: Question: will bundling of xml and pckl be allowed in this case?

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

 



On 04/26/2014 07:25 AM, Ralf Corsepius wrote:
On 04/25/2014 01:55 PM, Marcin Dulak wrote:
Hi,

i'm asking for a clarification/suggestions here before filling in an
exception request at https://fedorahosted.org/fpc.

I'm packaging a python software called gpaw:
https://bugzilla.redhat.com/show_bug.cgi?id=1087812
During the tests in %check gpaw uses some static xml and python pckl
data (these are definitions related to chemical symbols).
The data (gpaw-setups) belongs to gpaw (see
https://wiki.fysik.dtu.dk/gpaw/setups/setups.html),
and gpaw won't run without it, however gpaw and gpaw-setups are
versioned separately, and therefore
they need to be packaged separately (two separate spec files).
"need" ... no. It is technically possible to build several packages with different *version* numbers from one spec (E.g. we have been doing this in the perl package for a very long time).
OK

It's just that keeping packages separated usually is easier to handle, but there are occasions were bundling is easier.

gpaw-setups are being packaged here
https://bugzilla.redhat.com/show_bug.cgi?id=1090070

I'm asked by the reviewer to remove gpaw-setups bundling from gpaw.
Does the concept of bundling apply to this case?
Well, to me, this kind of bundling is technically not useful, because you would run the testsuite against a different dataset as a user would use at run-time.

Actually, I see 2 options for you:
- Keep gpaw-setup and gpaw as separate src.rpms.
Then, gpaw's testsuite needs to BR: gpaw-setup and use this when running the testsuite and not use a bundled gpaw-setup.
i'm going for this solution. %check will run gpaw-test no matter what release of gpaw-setups is available. The only concern is whether running the old gpaw release tests with new setups may hang/crash %check,
but in this case the gpaw.spec file can be edited to exclude such tests.
Already now (gpaw and gpaw-setups releases correspond) i had to exclude some tests due to the old scalapack available on Fedora/EPEL.

- Merge gpaw-setup and gpaw into one src.rpm.
Then, this package needs to also provide gpaw-setup, it then may use the bundled gpaw-setup files for its testsuite.

The problem is that each gpaw release requires a specific release of
gpaw-setups in order for the gpaw tests to pass.
It may happen that new gpaw-setups are released without a new gpaw release.
If the gpaw-setups corresponding to the gpaw release are not bundled in
gpaw one won't be able to run %check during a rebuild of gpaw.
gpaw-setups are bundled in gpaw.spec only for the purpose of %check.

While we're at it. Having had a brief look into gpaw-setup, I noticed gpaw-setup does not carry any indication of copyright, license nor origin.

That said, I think, gpaw-setup may not be used nor shipped with Fedora for legal reasons.
the license is now included in the gpaw-setups tarball.

Best regards,

Marcin

Ralf


--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux