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 > > 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 -- http://cecinestpasunefromage.wordpress.com/ ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
