Re: should I include tests in the package?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/04/2012 12:31 PM, Jon Ciesla wrote:
On Fri, May 4, 2012 at 10:24 AM, "Germán A. Racca"
<german.racca@xxxxxxxxx>  wrote:
On 04/30/2012 11:48 AM, Ralf Corsepius wrote:

On 04/30/2012 04:22 PM, "Germán A. Racca" wrote:

On 04/30/2012 11:09 AM, Tom Lane wrote:

=?ISO-8859-1?Q?=22Germ=E1n_A=2E_Racca=22?=<german.racca@xxxxxxxxx>
writes:

I'm the packager of APLpy: http://aplpy.github.com/
I'm going to update it to a new version, which comes with a set of
tests, but I'm not sure about what to do with them.


I think you do want to make the tests available to users, but they don't
necessarily have to be part of the base package.
If the tests are large relative to the base package, a fairly common
solution is to split them out into a sub-package, say aplpy-test.

(This is in addition to running them during the build.)

regards, tom lane


Hi Tom:

$ du -sh aplpy/
300K aplpy/

$ du -sh tests/
192K tests/

So I think that a split is not needed in this case.


This reasoning is dangerous:

a) Testsuites usually pull in further dependencies, which are not
required by the corresponding runtimes and therefore cause bloat.


Well, here I'm facing the problem that, for running the tests in %check
section (after %build), all the required packages for runtime are also
needed as BR.

Should I continue to run tests in %check and add the corresponding BRs? In
this case it'd be:

BuildRequires:  python-devel numpy python-matplotlib pyfits pywcs
Requires:       numpy python-matplotlib pyfits pywcs

Or should I stop because of this additional BRs?

No, go ahead, that's appropriate.

-J

Thank you Jon!

G.


Germán.

b) If everybody thinks the "These 100k more don't matter" way, the
distro very soon will have problems.


That said, my pragmatical recommendation would be

a) Only explicitly package a testsuite, if upstream explicitly support
this (I.e. if "make install" or similar install this testsuite). And if,
do so in a separate package.

b) Check carefully, if a test is actually designed to be externally
(often this does not apply) or if it's an internal "self-testsuite".

Apart of this, experience tells, *-test packages cause more trouble
thany they use and often are removed in not too distant future.


Ralf






--
Germán A. Racca
Fedora Package Maintainer
https://fedoraproject.org/wiki/User:Skytux
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging





--
Germán A. Racca
Fedora Package Maintainer
https://fedoraproject.org/wiki/User:Skytux
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux