On 4/7/21 5:14 PM, Vít Ondruch wrote:
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 they can get created (even if rare) then you'd want it to be removed
along with the package. Which having them %ghost'ed would achieve.
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.
Anybody can ship BRP but there's no drop-in mechanism to get then to
execute atm, you have to override %__os_install_post for that. So in
practise BRPs need to be enabled via central macros in
redhat-rpm-config, but there's no reason domain-specific BRPs could not
be enabled from there (even if the actual BRP lives in another package).
- Panu -
Vít
_______________________________________________
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
_______________________________________________
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
