FS#65283 - [ruby-unf] 0.2.0.beta2 is not recognized as "~> 0.1.0"
Attached to Project:
Community Packages
Opened by Erich Eckner (deepthought) - Monday, 27 January 2020, 08:53 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 31 May 2023, 22:52 GMT
Opened by Erich Eckner (deepthought) - Monday, 27 January 2020, 08:53 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 31 May 2023, 22:52 GMT
|
Details
Description:
gollum (from [quarry]) fails to start, complaining, that ruby-unf~>0.1.0 cannot be found: Traceback (most recent call last): 16: from /usr/bin/gollum:23:in `<main>' 15: from /usr/lib/ruby/2.7.0/rubygems.rb:295:in `activate_bin_path' 14: from /usr/lib/ruby/2.7.0/rubygems.rb:295:in `synchronize' 13: from /usr/lib/ruby/2.7.0/rubygems.rb:296:in `block in activate_bin_path' 12: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1373:in `activate' 11: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `activate_dependencies' 10: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `each' 9: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1405:in `block in activate_dependencies' 8: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1373:in `activate' 7: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `activate_dependencies' 6: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `each' 5: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1405:in `block in activate_dependencies' 4: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1373:in `activate' 3: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `activate_dependencies' 2: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `each' 1: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1402:in `block in activate_dependencies' /usr/lib/ruby/2.7.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'unf' (~> 0.1.0) - did find: [unf-0.2.0.beta2] (Gem::MissingSpecVersionError) Checked in 'GEM_PATH=/home/erich/.gem/ruby/2.7.0:/usr/lib/ruby/gems/2.7.0', execute `gem env` for more information I'm not sure, how ruby does version comparison and if that is maybe rather gollum's fault. Please let me know, if there is nothing wrong about ruby-unf. Additional info: * package version(s) ruby-gollum 4.1.4-4 ruby-unf 0.2.0.beta2-3 Steps to reproduce: set up quarry: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#quarry install ruby-gollum run /usr/bin/gollum (I'm sure, there is an easier way than this, but I have really almost no knowledge about ruby) |
This task depends upon
Closed by Toolybird (Toolybird)
Wednesday, 31 May 2023, 22:52 GMT
Reason for closing: None
Additional comments about closing: See comments
Wednesday, 31 May 2023, 22:52 GMT
Reason for closing: None
Additional comments about closing: See comments
Either way, that version constraint is a gollum/quarry problem not working together with that unf version.
To understand what happens here we need to look at the rubygems versioning policy.
Rubygems has two channels 'stable' and 'beta'. 'stable' is the released versions used by gem by default when they specify a dependency like 'gem "unf"'.
Here is what rubygems has in the stable repo for 'unf' gem:
```
gem info unf --remote
*** REMOTE GEMS ***
unf (0.1.4, 0.1.3)
Platforms:
0.1.3: jruby
0.1.4: java, ruby
Author: Akinori MUSHA
Homepage: https://github.com/knu/ruby-unf
A wrapper library to bring Unicode Normalization Form support to
Ruby/JRuby
```
For unclear reason `beta` unreleased version has been picked up and released as Arch default version. And now any package that expects "unf" gem is broken as the version expectation is not matched.
This need to be fixed whether by:
* releasing "ruby-unf" from stable rubygems. it is ok to have "ruby-unf-beta" that points to 0.2.0.beta2 if it is needed.
* or ask upstream to release the latest changes to stable rubygems channel.
Christian, please take a look.
Nothing to fix here, feel free to push ruby-unf1 if you require that
If packages in our repo require something and its absolutely unavoidable, in such rare situations we package git versions outside of latest tag or even a beta. It still remains the regular named package. if you need anything else that can't be patched to use that one as well, then a previously named variant gets introduced with a special naming schema.
This is nothing new, we do that for other packages, including non interpreted ones and interpreted languages like python (with exactly very comparable problems). Ruby is nothing special here compared to python or others. Surely we totally do not want to deliberately break downstream projects like quarry but that doesn't mean we forcefully must deviate from common naming schema and practice in Arch either, just to not require downstream (outside of arch repo land) to adjust their things.
Surely so!
Therefore here as well. If you need a semver-incompatible older version, then you can do exactly that using a slotted package. I fail to see anything here which hinders that.
unreleased beta (non-default) versions need to be slotted instead.
The only reason, why this does not apply here, is, that no official archlinux package trips over the ~>0.1.0 comparison, right?
Shouldn't "you can use it" be a sufficient reason to package the latest stable version of something (possibly next to a $pkgname-git version - if it is required by something)?
edit: oh, it looks, like I was misconceiving all those *-git packages - they are not really official packages, they all belong to the aur (but got merged in my memory)
It is a close analogy. In ruby world it gets a bit more complicated as a bunch of additional metadata checks happen during the loading stage.
In fact ruby versioning schema clearly defines what is stable and what is beta version https://github.com/rubygems/rubygems/blob/master/lib/rubygems/version.rb
If the version contains any letter then it going to be slotted as :prereleased.
Later at the dependency resolving stage it checks 'stable' releases first and if there are none then it will try to load any prereleased version. So if for example a Gemfile contains
gem :unf
then rubygems resolves it to the latest version of the gem that is currently:
$ curl https://rubygems.org/api/v1/versions/unf/latest.json
{"version":"0.1.4"}%
As you see beta versions do not count here.
ruby-$gemname packages should use the latest version of the gem. Using any other policy will diverge Arch packages from what all ruby developers (millions of people) use. And it just calling for problems.
Here is the explicit description of the very same schema and behavior in python land, except taking into account there can only be a single distribution being site-available
https://www.python.org/dev/peps/pep-0440/#handling-of-pre-releases
The whole section shows the resolution of pypi packages through pip is prioritized in the very same way.
which is reflected by pip, pip also handles the same class of versions as hidden, and has a special switch for it:
--pre Include pre-release and development versions. By
default, pip only finds stable versions.
Version specifiers are the very same for pkg_resources version constraint resolution orthogonal to ruby version constraints which can be specified in setup.py and during loading time of an application/module using pkg_resources loading with a version constraint the loader checks and exits with VersionConflict.
So we can clearly observer this is the very same case for python as well. When we are forced to such a version pre version in python, it also differs for users compared to something they would get through a pip install.
What really matters is this question: Do we need that one version for a dependency in _our_ repository to work correctly (runtime or test)? If so, we may need to patch reverse deps to constraint on it so its not down slotted during resolution when having other variants available.
So taking everything into account, all of this does absolutely *zero* _behaviour_ change whenever the _pacman_ package is called ruby-unf0.1 or ruby-unf-beta, ruby doesn't magically query pacman. Still we don't rename our packages -beta during such a bump and once a stable release is out back to the regular package name whenever we are forced to bump to such an "invisible" version, no matter which language. In Arch greatest version variant ist regular variant and any special variant has a version constrained name.
The game blocker for a stable ruby-unf release is a working puppet 6.12 release. This has top priority for me now.
As long it's not clear if ruby-unf stable will work with puppet 6.12 as long I am not really willing to rename the package, because of several reasons:
1. a ruby-unf-beta package would break our pkgname policy
2. I don't want to mess around with pkgrel. If ruby-unf-1:0.1.0 (stable) suddenly doesn't work with puppet 6.12 we would need to ship ruby-unf-2:0.2.0beta2, because we don't want to break our pkgnanem policy (ruby-unf-beta package is not possible).
3. The affected package 'gollum' is from an unofficial third party repository, since when do we care about third party repositories? This might sound harsh, but I am a fan of equality, if we start caring about third party packages, we need to care about all third party packages, and this is a decision nobody should decide in a bugtracker.
So what can we do now? It's plain simple:
I will further work on a puppet 6.12 release and I will test this puppet 6.12 release with ruby-unf stable and ruby-unf beta. If the stable versions works fine, we can still downgrade to ruby-unf stable via pkgrel bump. If not, we have the status quo and we keep shipping ruby-unf-0.2.0beta2. If you want to speed up this process, you are free to help with maintaining more test dependencies for puppet 6.12, helping out with the new puppet 6.12 PKGBUILD. This way we can finally test a fully working puppet 6.12 package. It's the only way to get to know if ruby-unf stable would really work with the puppet release.
So much about the ruby-unf problem...
The gollum package problem (@Erich):
Did you try setting "=> 0.1.0" in the gemspec of gollum? This might fix your issue. If not: Did you consider using bundler to build a working gollum version?
Another option is: The quarry repository adds an own ruby-unf0.1 package and you just use this one.