From Fedora Project Wiki
Martinpitt (talk | contribs) (resolve my points about discoverability and rpm packaging, addressed in the spec now) |
No edit summary |
||
| Line 5: | Line 5: | ||
# tflink: As I understand it, the proposal requires <code>-test</code> subpackages to either have globally-unique file names or explicit <code>conflicts</code> in the spec file. Why not use a subdirectory matching the <code>name</code> from the specfile e.g. <code>/usr/tests/gzip</code> for the gzip packaged tests? That would make filename conflicts much less likely and would be one less thing for packagers to worry about when including tests. | # tflink: As I understand it, the proposal requires <code>-test</code> subpackages to either have globally-unique file names or explicit <code>conflicts</code> in the spec file. Why not use a subdirectory matching the <code>name</code> from the specfile e.g. <code>/usr/tests/gzip</code> for the gzip packaged tests? That would make filename conflicts much less likely and would be one less thing for packagers to worry about when including tests. | ||
#* MartinPitt: Excellent point; spec changed to <code>/usr/tests/</code>''srcpkgname''<code>/</code> to make use of the already unique name space that source packages (aka. spec file names) give us. Will that be sufficient to map a source package to all of its binary packages that contain tests? I. e. "give me all rpms of the <code>gtk+</code> source that provide tests? | #* MartinPitt: Excellent point; spec changed to <code>/usr/tests/</code>''srcpkgname''<code>/</code> to make use of the already unique name space that source packages (aka. spec file names) give us. Will that be sufficient to map a source package to all of its binary packages that contain tests? I. e. "give me all rpms of the <code>gtk+</code> source that provide tests? | ||
# pingou: | |||
* Execute all executable files in /usr/tests/*/ directories one at a time. | |||
This is a neatpick but there will be people complaining about it since /usr/tests isn't in the FHS and isn't really a good place for executable, we could suggest using /usr/libexec which is meant for executable and put a /test subfolder there | |||
* I honestly do not see the advantage of packaging the tests. I doubt that for most project upstream is going to release them as a tarball which means the packagers will have to do that. Then write down the process on how to execute them. Why not doing this with something like ansible from the start? It makes it easy to list the dependencies (just install them in one task). Then you would need to specify how the tests should be run, which can be just as easily done in ansible. It also means that we would have to go through the FPC to get this approved in the packaging guideline, for imho little benefit. | |||
Revision as of 12:25, 30 March 2017
- AliVigni: In invocation why would I want to hardcode absolute paths for test execution, artifacts, logs, This should be a relative path so where ever you run things it is in the local workspace. My machine, Jenkins, taskotron, etc.
- MartinPitt: I reworked the invocation; it was also impractical for tests that run as non-root, and it would have potentially clobbered the root directory with temporary stuff.
- tflink: As I understand it, the proposal requires
-testsubpackages to either have globally-unique file names or explicitconflictsin the spec file. Why not use a subdirectory matching thenamefrom the specfile e.g./usr/tests/gzipfor the gzip packaged tests? That would make filename conflicts much less likely and would be one less thing for packagers to worry about when including tests.- MartinPitt: Excellent point; spec changed to
/usr/tests/srcpkgname/to make use of the already unique name space that source packages (aka. spec file names) give us. Will that be sufficient to map a source package to all of its binary packages that contain tests? I. e. "give me all rpms of thegtk+source that provide tests?
- MartinPitt: Excellent point; spec changed to
- pingou:
- Execute all executable files in /usr/tests/*/ directories one at a time.
This is a neatpick but there will be people complaining about it since /usr/tests isn't in the FHS and isn't really a good place for executable, we could suggest using /usr/libexec which is meant for executable and put a /test subfolder there
- I honestly do not see the advantage of packaging the tests. I doubt that for most project upstream is going to release them as a tarball which means the packagers will have to do that. Then write down the process on how to execute them. Why not doing this with something like ansible from the start? It makes it easy to list the dependencies (just install them in one task). Then you would need to specify how the tests should be run, which can be just as easily done in ansible. It also means that we would have to go through the FPC to get this approved in the packaging guideline, for imho little benefit.