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-...
>>>
>>>
>>>
>>> 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