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 -