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

[Marcin Dulak]

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

[Ralf Corsepius]

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

[Marcin Dulak]

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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/packaging