On 20/04/2023 11:50, Jon Turney via Cygwin-apps wrote:
On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote:
On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote:
Hello,
====
Cygportfile:
-
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby
Looks fine. Thanks very much for updating this!
Packages, logs:
- https://github.com/cygwin/scallywag/actions/runs/4743191979
all yours
Are you planning to adopt also the ruby-* sub-packages ?
Regards
Marco
I have a concern about how this changes a soversioned dll inside the
package (from cygruby260.dll to cygruby320.dll)
I don't know if there's anything linked against this DLL (perhaps ruby
bindings provided by other packages) which will get broken?
Please hold off on uploading this until I have a chance to look into
that issue a bit more.
It seems we have a handful of ruby binding packages, which install a .so
file into /usr/lib/ruby/vendor_ruby/2.6/ which is linked against
cygruby260.dll:
ruby-gv
ruby-marisa
ruby-openbabel
ruby-openwsman
ruby-solv
ruby-xapian
ruby-zinnia
subversion-ruby
(There might also be some other packages which link with that dll to
embed the ruby interpreter or something, but those are harder for me to
identify quickly...)
I think this can be handled in the same way as perl, i.e. add something
like "ruby_PROVIDES=ruby_${${VERSION%.*}//./}" to ruby.cygport, and add
a mechanism to cygport to make the binding packages have an additional
dependency on that provide.
I'll look into retroactively adding this to the existing ruby 2.6.x
packages, to prevent non-working combinations of packages getting installed.
