Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/6/21 3:01 PM, Tim Landscheidt wrote:
Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:

[…]

2. change %check not to rely on unpackaged files in buildroot

That one is non-trivial and depends on the reason it is needed.

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.

[…]

My understanding of the RPM spec sections was always that:

- "%prep" is for "./configure",
- "%build" is for "make",
- "%install" is for "make install", and
- "%check" is for "make check".

"make check" (usually executed /before/ "make install")
works in and on the working directory
(https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets).

Exactly. Only rpm got this sequence wrong, because %check is executed after %install. If it wasn't for that, we wouldn't be having this conversation at all because then %check would be clearly defined.

For the curious, this is how %check came to existence:
https://bugzilla.redhat.com/show_bug.cgi?id=64137

I'm kinda wondering here if there wouldn't be any solutions to in this direction - the existing %check is being (ab)used for things its not well suited to because it's positioned in the way it is, and people be better off with something different entirely.


To test that the resulting binary package is functional, an-
other venue is needed, and in the case of Fedora, for that
purpose Fedora CI was created
(https://docs.fedoraproject.org/en-US/ci/tests/).

That feels like a much cleaner solution than installing some
files, testing and then not shipping them because the test
environment will be the same as a user's who just installed
the package instead of being in the process of building the
package.

Indeed.

	- 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux