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
