On 04/30/2012 04:54 PM, Jon Ciesla wrote:
On Mon, Apr 30, 2012 at 9:48 AM, Ralf Corsepius<email@example.com> wrote:
On 04/30/2012 04:22 PM, "Germán A. Racca" wrote:
On 04/30/2012 11:09 AM, Tom Lane wrote:
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
$ du -sh aplpy/
$ du -sh 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.
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.
Exactly, hence my suggestion to put it in %doc, to prevent deps,
though it doesn't help with disk space as much as leaving it out.
This also is not safe. Probably all perl-package packagers have their
own story on installing testsuites as %doc.
Background: rpm and the rpm perl module deptracker repeatedly have
accidentally pulled in deps on certain kind of files in %doc. (I don't
know, if these issues are terminally resolved in all active versions of
Fedora and RHEL).
This experience has caused me to generally avoid packaging non-doc files
packaging mailing list