6:55 a.m.
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).
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?
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.
Best regards,
Marcin
12:25 a.m.
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).
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.
- 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.
Ralf
9:25 a.m.
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
3648
days inactive
3653
days old
packaging@lists.fedoraproject.org
2 comments
2 participants
participants (2)
-
Marcin Dulak -
Ralf Corsepius