-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hello folks.
Current Packaging Guidelines [1] don't say anything about the %check script, so the only source of _documentation_ for now is the mere paragraph from Maximum RPM [2] which states: " This script's primary function is to run the test suite of the built software to ensure that the binaries work correctly. Some typical commands to run in this script are make test or make check. "
Ok, nothing new for now, but there is one footnote [3] there: " One popular hack to make spec files containing the %check script work with RPM versions older than 4.2 roughly similarly as in newer versions is to include it immediately after the %install script in the spec file and append '|| :' to it, like: %check || : "
Fedora Extras team (seeing provided template specs from fedora-rpmdevtools) and everybody in fact (reviewing prior discussions on the various Fedora related channels - mailing list, websites) seems to agree on this and already started using this procedure on some of the current packages in Fedora Core/Extras.
The hack suggested in [3] ("%check || :" _after_ %install) and the testing done determined that this %check is done after %install (sort of "%__spec_install_post").
So, here come my issues: a) Maybe I really don't get it (reading [2] again and again), but it seems more appropiate to append this %check to %build (or even prepend it to %install), but I see no point for doing it _after_ %install. b) What is the "easy" way to disable %check? "--define 'check exit 0'" doesn't sound as "easy" as e.g. "--without check".
Ok, b) is more like a rant or something, but a) bothers me a lot. Before knowing about this %check, I was adding a %{!?_without_test:make test} to the %build script and this seems good enough for me. Why should I "upgrade" to using this %check script?
TIA.
References: [1] http://fedoraproject.org/wiki/PackagingGuidelines [2] http://rpm.org/max-rpm-snapshot/s1-rpm-inside-scripts.html [3] http://rpm.org/max-rpm-snapshot/s1-rpm-inside-scripts.html#FTN.AEN8053
- -- Marius Feraru http://www.altblue.com/ "It isn't easy being the parent of a three-years-old. However, it's a pretty small price to pay for having somebody around the house who understands computers."
On Mon, 2005-06-27 at 01:59 +0300, Marius Feraru wrote:
The hack suggested in [3] ("%check || :" _after_ %install) and the testing done determined that this %check is done after %install (sort of "%__spec_install_post").
So, here come my issues: a) Maybe I really don't get it (reading [2] again and again), but it seems more appropiate to append this %check to %build (or even prepend it to %install), but I see no point for doing it _after_ %install.
The Max-RPM hack suggests placing "%check || :" after %install, because that's the order rpmbuild >= 4.2 also runs the two in, no matter what their order is in the specfile.
Off the cuff, I guess that the install-before-check order is because non-well-behaving test suites may modify/add/remove files in the build root which can affect what files get installed by the %install section. Which is obviously not acceptable.
Can you come up with a generic case where running the test suite before doing the staged install would be useful? I cannot at the moment.
b) What is the "easy" way to disable %check? "--define 'check exit 0'" doesn't sound as "easy" as e.g. "--without check".
Right, but it doesn't have to be easy :) Just make it a habit to disable the test suite only when _absolutely_ necessary. In those rare cases, the --define way should not be too "hard", and keeps the specfile (very) slightly more readable.
If a test suite of a package does or requires something that is not appropriate (taking into account all situations where it might be run in, generic/minimal build roots and personal workstations or desktops etc.), report a bug against the package.
Ok, b) is more like a rant or something, but a) bothers me a lot. Before knowing about this %check, I was adding a %{!?_without_test:make test} to the %build script and this seems good enough for me. Why should I "upgrade" to using this %check script?
Mileages vary, but I'd suggest at least running the test suite after %install, no matter what way you choose. Also, conditionalizing the build on a "--without test" or the like will obviously work only for that particular package, whereas "--define 'check exit 0'" should work for all packages that use %check, which are the majority already of ones that run test suites in the first place.
Personally, I usually use the %check section just as is. In cases the test suite requires or does something inappropriate, I just write the "make test" and friends in the %check section, but comment them out along with a note stating why. Or add a "--with tests" flag that enables the test suite if it can be configured properly in the build root, but I don't remember ever adding a "--without tests" flag, nor using "--define 'check exit 0'", nor do I plan to do either :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jun 27, at 20:45 (+0300), 'Ville Skytt�' wrote:
Can you come up with a generic case where running the test suite before doing the staged install would be useful? I cannot at the moment.
Hm, my mileage varies a lot on this, as I would rephrase it quite the opposite: what would be the generic cases where a staged install is necessary for running its test suite? I cannot at the moment :))
But anyway, I'll answer your question: perl modules (and obviously not only). Remember the adviced way of install a module: perl Makefile.PL make make test make install ^ as you see, "install" _after_ "test"
I could bring you more examples (OFC, not perl related - mysql e.g.), but I'm sure it's not really necessary. Better - risking to repeat myself - I'll try to explain again my point/opinion: "%check" at the end of "%install" is GOOD. I argue that its current use is BAD, as in using it for "make test", which testing IMHO has nothing to do with the staged installation.
Now, I'll explain (again) why this testing after install bothers me alot: because I cannot easily repeat testing, previously done with: rpmbuild -bc --short-circuit pkg.spec Using "make test" in "%check" nowadays just makes my delay (much) longer, as you surely know what a PITA currently are the various scripts run in _spec_install_* (e.g. the dependencies checking).
So, for the last time, please don't understand me wrong - I'm not against the existence of a "check" script, but against the "policy" to use that block for "make test" & co.
b) What is the "easy" way to disable %check? "--define 'check exit 0'" doesn't sound as "easy" as e.g. "--without check".
Right, but it doesn't have to be easy :)
Sorry, I'm on a different side again, but I surely understand (and sometimes even agree) that enforced rules should more seldom drive into sloppy development comparing to systems/rules/policies promoting self discipline. Anyway, I'll stop here with this, I prefer not to get into advocacy stuff.
If a test suite of a package does or requires something that is not appropriate (taking into account all situations where it might be run in, generic/minimal build roots and personal workstations or desktops etc.), report a bug against the package.
Hm, as long as the packager provides clarifying BuildRequires, I see no problem with that.
Mileages vary, but I'd suggest at least running the test suite after %install, no matter what way you choose.
OK, I understand now that I failed explaining my premises in my previous message. I hope now you understood that I'm NOT trying to avoid testing, but just trying to ease packagers' jobs.
cheers. - -- Marius Feraru http://www.altblue.com/ "It isn't easy being the parent of a three-years-old. However, it's a pretty small price to pay for having somebody around the house who understands computers."
On Tue, 2005-06-28 at 22:52 +0300, Marius Feraru wrote:
On Jun 27, at 20:45 (+0300), 'Ville Skytt' wrote:
Can you come up with a generic case where running the test suite before doing the staged install would be useful? I cannot at the moment.
Hm, my mileage varies a lot on this, as I would rephrase it quite the opposite: what would be the generic cases where a staged install is necessary for running its test suite? I cannot at the moment :))
It's not necessary nor does it really have anything directly to do with it. But in the vast majority of cases, the test suite must not affect what gets installed. I think running tests after the staged install is a cheap way to be almost certain that it doesn't happen, even if whatever does the staged install would be buggy as in "too lax wildcards", or if the test suite would be buggy as in "modifies/removes files to be installed" or the like. (Of course this assumes we're dealing with non-malicious software. If not, none of this matters anyway.)
But anyway, I'll answer your question: perl modules (and obviously not only). Remember the adviced way of install a module: perl Makefile.PL make make test make install ^ as you see, "install" _after_ "test"
Sure, but that's different. In the above case, you're actually _installing_ stuff into their final runtime locations, not doing a staged install the results of which will be installed to their runtime environment later. The above advice applies well to the situation it documents ("how to install these modules"); not doing it that way would be shooting before asking. But it applies less well in packaging IMO.
Now, I'll explain (again) why this testing after install bothers me alot: because I cannot easily repeat testing, previously done with: rpmbuild -bc --short-circuit pkg.spec Using "make test" in "%check" nowadays just makes my delay (much) longer, as you surely know what a PITA currently are the various scripts run in _spec_install_* (e.g. the dependencies checking).
With %check blocks in use, you can work around that PITA if you want to stick with rpmbuild alone:
rpmbuild -bi --short-circuit --define 'install exit 0' foo.spec
Not quite as short as your example above, and may spew errors about unpackaged files, though. But doable. Another way would be to do a rpmbuild -bc, cd into the build root, and run the test suite manually.
I'm not against the existence of a "check" script, but against the "policy" to use that block for "make test" & co.
What else would it be useful for?
If a test suite of a package does or requires something that is not appropriate (taking into account all situations where it might be run in, generic/minimal build roots and personal workstations or desktops etc.), report a bug against the package.
Hm, as long as the packager provides clarifying BuildRequires, I see no problem with that.
There are things that a packager may want to test locally but which cannot be specified as build dependencies, nor even completely written in the specfile by other means so that they would apply everywhere.
For example, testing database drivers which require a running database and the configuration to access it, or test suites that require internet access, or stuff that can be only run as root, or need some files outside of the build root somewhere, or import GPG keys, to name a few I've seen.
Mileages vary, but I'd suggest at least running the test suite after %install, no matter what way you choose.
OK, I understand now that I failed explaining my premises in my previous message. I hope now you understood that I'm NOT trying to avoid testing, but just trying to ease packagers' jobs.
Yep, got it. And I'm just another package monkey explaining one's understanding of the %check script/block, and opinions on running test suites as part of rpmbuild in general, FWIW. I'm slightly advocating %check over other "homebrew" solutions because the former is a standard part of rpmbuild which behaves in a certain predictable way (as such), which cannot be said of the latter without massive coordination efforts and agreements between packagers. Computers vs. packagers (humans, yuk :)) and their opinions, kind of.
packaging@lists.fedoraproject.org
-
Marius Feraru -
Ville Skyttä