On 4/7/21 11:45 AM, Panu Matilainen wrote:
On 4/6/21 7:40 PM, Vít Ondruch wrote:
Dne 06. 04. 21 v 16:02 Panu Matilainen napsal(a):
On 4/6/21 1:36 PM, Miro Hrončok wrote:
For example, what is common for Python "namepsace" packages, e.g.
pkg_name.foo.
1) We want to test installed files, not what is in $PWD, so we set
PYTHONPATH to
%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
(try hard to) exclude $PWD from it. This is crucial to ensure
the files
we actually ship are working and the installed file set is
complete.
Our macros do this for the packagers.
2) The %{python3_site...}/pkg_name/ directory and
%{python3_site...}/pkg_name/__init__.py and
%{python3_site...}/pkg_name/__pycache__/ and
%{python3_site...}/pkg_name/__pycache__/__init__...pyc
files must be present in %{buildroot} to successfully run the
tests.
3) The files from (2) must be excluded from the package because
*pkg_name* owns
them, not *pkg_name.foo*.
We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
The files are not bit-by-bit+metadata identical,
so both packages cannot ship them.
This seems like a fairly exotic case to me - okay, a Python-peculiar
problem. And a problem of stepping (not saying crossing, because I'm
not sure it is) on the boundaries of the %check use-case I suppose.
%ghost'ing the files might be one option - I don't know about the
Ruby cache case beyond that there is one.
There is only `%{gem_cache}` (I assume it was mentioned in the context
of `%exclude`, because that has nothing to do with testing). Not
shipping this file is enough and we don't ship it just because we
don't want to ship file which looks like upstream file but it is not
the original upstream file. Moreover we don't really need it for the
purposes it is used by upstream, which is restoring the original state
of the library.
Ah, okay, it's an entirely different case then. Does this file ever get
created when running the installed software (by root)? If so, then
%ghost'ing it would seem to be the right thing.
If it's just something that needs to be scrubbed on each and every ruby
package ever built, we could always add a buildroot policy for it. Just
like we could automatically clean .la files rather than manually clean
them in thousands of packages...
But since Ruby was mentioned there, we generally run test suite in
`%{_builddir}` (and there are (unfortunately) two possible location,
while only one is preferred). Generally, it could be run in
`%{buildroot}` with similar results, but it should be discouraged due
to possible `%{buildroot}` pollution.
Ok, good. Indeed, buildroot should not be used by %check because it can
and often does have side-effects.
I'm starting to think the right thing to do is to move %check to run
after %build rather than %install. That would completely eliminate
arguments over what is proper use and should this or that be done etc.
https://github.com/rpm-software-management/rpm/pull/1618
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
