Dne 17. 06. 21 v 13:26 Ewoud Kohl van Wijngaarden napsal(a):
On Wed, Jun 16, 2021 at 02:21:18PM +0200, Vít Ondruch wrote:
Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a):
On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote:
Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):
On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:
On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:
If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged
module)
*MUST* be run in `+%check+`.
A simple scriplet should be introduced I think:
%check
%do_import_test
Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
This may be not be the right place, but in Foreman's Ruby
packaging we've also felt a similar pain. Mostly with C extensions
that were built in the wrong directory. We also added a %check
section to do a basic "import" (require) test.
Is there a similar macro for Ruby smoke testing?
No, there is no similar macro for Ruby. Historically, it was not
clear what should be actually required. With Bundler putting into
place more conventions, the situation is better.
Nevertheless, what is the specific issue you are referring to
above? There are many examples of fixing such issue, e.g.
https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52
And there are probably more complex cases.
Perhaps we should take this to a separate discussion, but we found
that there are various bugs in SCL macros that s.o ended up in the
wrong directories so it wouldn't load.
SCLs or not, this is what always happens for several reasons:
1) While upstream leaves the .so files along side other parts of the
library, we place the platform independent code in /usr/share while
placing the platform dependent code into /usr/lib. This is done via
[1] and it was actually supposed to be default in RubyGems 3, but
unfortunately with change of upstream maintainers, it got forgotten [2].
2) The paths used during rpmbuild are never on Ruby LOAD_PATH.
Upstream might add the `lib` directory on the load path, which be
defaults contains the .so file. But that is not case on Fedora as I
explained in (1), therefore it is always necessary to add the
directory with .so file on the LOAD_PATH explicitly.
In theory, we could somehow extend the GEM_PATH to include the RPM
directories, but upstream test suites are not prepared for this
scenario, so it would not help.
Really, majority of Ruby packages has fragments like `-Ilib` or
`-Ilib:test` in the `%check` section. This is grep across the Fedora
.spec files [3]:
~~~
$ find . -name rubygem\* -exec grep ' \-I' {} \; | wc -l
311
~~~
You just need to add the path to the .so file on the LOAD_PATH
similarly.
That does leave a feeling that we can't test the correct .so location
at all in %check.
Right, you can't. You never work with correct locations during rpmbuild.
The location can be just faked for better or worse. The correct .so
location can be tested only via integration tests which are run outside
of rpmbuild environment.
Please note that neither upstreams test the "correct" location, they are
faking them just to the extend to have their test suite green. That does
not mean the test suite necessarily follows all conventions.
It feels like we need a phase where the package was installed
(respecting %files and all). If we can *then* import the library using
Ruby, then we're content. While it may not be RPMs job, an easy
verification point that's also usable outside of some fixed
infrastructure (such as Fedora) would be great. Is there such a thing
today?
Yes, you can use CI:
https://docs.fedoraproject.org/en-US/ci/
And Fedora actually runs some test by default:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-be0f7a99dd
But there is unfortunately no generic smoke test, which would try to
load the library from the right location.
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
