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