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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging