On 11/24/22 14:20, Vít Ondruch wrote:

Dne 24. 11. 22 v 13:12 Jarek Prokop napsal(a):
nit regarding the spec license, "GPL-2.0" is not valid SPDX (according to license-validate at least), however, there is "GPL-2.0-only" or "GPL-2.0-or-later".


I think that it used to be valid identifier at some point in time. This should be fixed in rubygem-rdoc then:

https://src.fedoraproject.org/rpms/rubygem-rdoc/c/5e165eed4822757b49dd3b1219dd4b7a024cb336?branch=rawhide

but mainly upstream:

https://github.com/ruby/rdoc/issues/924

Right


On 11/23/22 17:47, Vít Ondruch wrote:

FedoraRDoc.generation_hook - the `specs` could be modified to include additional `rdoc_options`


Eh, have I left the message ^^ there? :)
It seems so https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/tree/rubygems_plugin.rb?h=rawhide&id=487234ef5f64f78291ce767a8a989649ee941c73#n24 :)

This succeeds with only generating rdoc, ignoring ri format:
~~~
$ gem uninstall chronic; gem install ./chronic-0.10.2.gem --document=rdoc --local
Successfully uninstalled chronic-0.10.2
Successfully installed chronic-0.10.2
FedoraRDoc.generation_hook - the `specs` could be modified to include additional `rdoc_options`
Parsing documentation for chronic-0.10.2
Installing fedora::darkfish documentation for chronic-0.10.2
Done installing documentation for chronic after 1 seconds
1 gem installed
~~~


Good catch. I was testing plain `--document=rdoc`.

Hm, there should be probably done some early matching, if the `fedora::` prefixed generator is there. Otherwise just move on with whatever was specified.

Something along those lines. Maybe this:
~~~
generator = "fedora::#{generator}" if generator == "rdoc"
~~~

In regards to tests (%check):
What we want to test is: We can generate the documentation in context of Fedora (IOW, `gem install` passes with `--document=rdoc,ri`)
and then validate that anything that is an image, or JS file that is not "search_index.js" is symlinked to the template and that there are no fonts present,
as those are the places where we differ from the tested upstream behavior.

This would help us catch any major regression that I can think of, at build time, hopefully being a step ahead of accidentally breaking rubygem builds.


I have not spend too much time thinking about %check section yet, but something along these lines seems reasonable.

RDoc generators could have rubygem-rdoc-generator-* if we would want to mandate prefixes, but that would come with new packaging guidelines, etc...
This iteration does not have rubygem-* prefix as it is not a gem, so I would say, this is the odd case :).


Lets leave future problems for future us. So far, there is no other RDoc generator and I don't see any other generator coming any time soon, so lets ignore the `rubygem-` prefix for now. This still might end up as a gem after all :)
Agreed.


PTAL and let me know what do you think about this approach. Thx

I'd say we are on the right path with this.


Thx. Next thing to consider is how to enforce the dependency on the -assets. There should probably be included some generator, otherwise we would need to update gem2rpm as well as every gem.
I vote for a generator.

Also, the other question is how to pull this into the build root. Should this be pulled in by rubygems-devel? Shouldn't it even be part of rubygems-devel?

To this point: https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby.spec#_319

Line 324: `# Needed for RDoc documentation format generation.`

So perhaps we want it as part of the rubygems-devel. Theoretically, we can sweep it under the rug
and add a conditional depending on some RPM build specific env variable in the RubyGems plugin.

Or shouldn't this be opt-in, where one needs to specify this explicitly?
Maybe just from the beginning unless we are sure this does not cause more troubles then it solves?

I think we could provide some macro options, but I'd make them opt-out for gems where it does indeed cause troubles?

Or in gems where one wouldn't want documentation.

Something like `%gem_document_options` containing `rdoc,ri` and then we can do `gem install ... --document=%{gem_document_options}` . I think packager should then be able to `%define gem_document_options %{nil}`, which disables documentation as
`gem install --document=` does nothing but create the gem's doc directory documentation-wise.

Just throwing ideas right now.

Jarek



Vít