Dne 26. 10. 22 v 11:59 Jarek Prokop napsal(a):
Hi,
> Sub-clasing is interesting idea. But that would mean we needed to
> provide our own generator.
>
>
I am working on a kind of a prototype on this.
Sources with specfile are available here:
https://fedorapeople.org/cgit/jackorp/public_git/fedora_darkfish.git/
I also created copr repo that contains the newest build:
https://copr.fedorainfracloud.org/coprs/jackorp/fedora_darkfish/packages/
I have been successful with hijacking Rubygems documentation
generation via the plugin
Interesting. I was against making gem out of this, but the RubyGems
plugin mechanism seems to be convincing. This would give us a way to
control the behavior just by installing the plugin (and the pluging
would be presumably pulled in just via the rubygems-devel). So if the
plugin is installed, the custom generator is used, if it is not
installed, then the default generator is used.
That seems convincing comparing to modifications of operating_system.rb
I was considering previously. This would avoid the (negligible) runtime
impact.
I am afraid we won't dodge monkey patching here due to the lack
of
parametrization of the documentation generator options.
I will need to experiment with this idea a bit.
Following, I can uncomment the following line:
https://fedorapeople.org/cgit/jackorp/public_git/fedora_darkfish.git/tree...
which would hopefully enable this only when we are in an RPM build. I
do not expect this package to be installed outside of an RPM buildroot
for a regular user.
That is probably not necessary at all. Either it is installed and it
does its job or it is not installed. I would not bother with this. KISS.
Interestingly enough, I was not successful in monkey patching outside
of the Gem hooks (pre_install etc...).
This might get quickly complex and patch the right thing might not me easy.
Next possible steps are:
* Patch rdoc with this patch
https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/tree/rdoc-...
However I am afraid we might break something...
In worst case, the fonts will be broken in a way that there will be used
some different font. Browsers are ready for this.
* Require fonts for rdoc and/or add font requires to doc subpackages.
We can maybe add implicit font requires via some already used
macros, but that is just an idea so far.
Well, the whole -doc subpackage is pretty static piece of code. So it
could be replaced by some macro, which in turn would need to modify
gem2rpm and all packages.
The other option might be custom RPM generator. That might be naively
checking path and if there is path such as something like
`/usr/share/gems/doc/gem2rpm-1.0.2/rdoc`, just put there the font requires.
Actually, I still prefer if the template was extracted (as in my
example), because it is not just about the fonts. So there should not be
dependency on the fonts but on the template-asset package.
Another thing I am concerned about are the symlinks. Maybe we should
split the static darkfish template files into a subpackage, add font
requires on that, and have -doc subpackages depend on that,
Right.
so that we don't pull the whole rdoc when we want just the
specific
static files.
You are thinking in the right direction ;)
Vít