On 21/04/2023 20:36, Daisuke Fujimura via Cygwin-apps wrote:
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`.
This isn't needed. I've retroactively modified the existing 2.6.4-1 and
2.6.3-1 packages to have this provide.
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
Yes.
I'm not asking you to do this work though, unless you really feel like it :)
3. Rebuild `ruby-*` subpackages.
Again, this isn't needed as I can retroactively modify existing packages.
- The new cygport adds `depends: ruby_26` to the hint.
I've retroactively added this to the packages listed below, which
install into /usr/lib/ruby/vendor_ruby/2.6/ a .so linked to cygruby260.dll:
- (Question) Does a gem that has no dependencies on `cygruby*.dll`
need to rebuild?
I don't really know enough about ruby to answer that question, but
I don't think so.
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.
Yes.
The idea is that this will ensures that packages which are installed
together will work together, going forwards.
On Fri, Apr 21, 2023 at 1:13 AM Jon Turney 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
ruby-caca also belongs on this list, but the ruby binding hasn't been
rebuilt since ruby 2.3.0
Additionally, there are some packages which install a .so into
/usr/lib/gems/ruby/2.6/, which probably need similar treatment?
(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.
