Dne 07. 04. 21 v 11:05 Panu Matilainen napsal(a):
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.
The chances to have this file created are pretty slim end even if it was
created, it would not be trustworthy.
>
>
> 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...
Is it correct assumption that any "random" packages can ship BRP?
Interesting idea, I have to give it thought. I guess the concern would
be that the packages for the most recent Fedora/RPM won't be compatible
with older releases without the BRP. But it should be possible to
backport it I guess.
Vít