Thank you for your review. Based on your review, I understand that the following steps are necessary.
Could you please let me know if it is correct? 1. Release `ruby-2.6.4-2`. - Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport. - The value of this variable will be `ruby_26`. - `provides: ruby_26` is added to `ruby-2.6.4-2.hint`. 2. Modify cygport and release it. - Add code to detect dependencies on `ruby_xy`. - It is similar to the process for `perl5_xy0`. - https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442 - https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639 3. Rebuild `ruby-*` subpackages. - The new cygport adds `depends: ruby_26` to the hint. - (Question) Does a gem that has no dependencies on `cygruby*.dll` need to rebuild? 4. Release `ruby-3.2.2-1`. - The value of `provides` becomes `ruby_32`. - Packages that depend on `ruby_26` will no longer be installable. 5. Rebuild `ruby-*` subpackages. - The rebuild adds `depends: ruby_32` to the hint. On Fri, Apr 21, 2023 at 1:13 AM Jon Turney <jon.tur...@dronecode.org.uk> wrote: > > 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. >