Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



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:
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
Comment by Levente Polyak (anthraxx) - Monday, 27 January 2020, 09:38 GMT
Well its not optimal to package a beta, but this software is essentially dead and wont get any more commits on top (but the latest beta is required for other dependencies).
Either way, that version constraint is a gollum/quarry problem not working together with that unf version.
Comment by Levente Polyak (anthraxx) - Monday, 27 January 2020, 16:40 GMT
There is no need to reopen this ticket, we have software which gem specs require ~> 0.2.0 duo to changes and gollum has nothing to do wich any Arch Linux package in the repos.
Comment by Anatol Pomozov (anatolik) - Monday, 27 January 2020, 16:48 GMT
Levente, please do not rush to close the task until the problem is fixed.

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


unf (0.1.4, 0.1.3)
0.1.3: jruby
0.1.4: java, ruby
Author: Akinori MUSHA

A wrapper library to bring Unicode Normalization Form support to

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.
Comment by Anatol Pomozov (anatolik) - Monday, 27 January 2020, 16:49 GMT
Levente, there is a clear problem with misusing rubygems versioning. It needs to be fixed.
Comment by Levente Polyak (anthraxx) - Monday, 27 January 2020, 16:50 GMT
There is nothing to take a look, gollum is not an official package and we require 0.2.0.beta2 for official packages. if there is something that requires ruby-unf 0.1 we can do the same as we do for all packages in arch: have something like ruby-unf1 or similar.
Nothing to fix here, feel free to push ruby-unf1 if you require that
Comment by Anatol Pomozov (anatolik) - Monday, 27 January 2020, 16:59 GMT
Levente, see the output from gem above. 0.1.4 is the latest stable release and it needs to be used for the Arch packages. If you want to release `beta` software then please use proper Arch naming. Mixing beta and stable gems versioning is the best way to get problems.
Comment by Levente Polyak (anthraxx) - Monday, 27 January 2020, 17:06 GMT
The point is, we use arch naming, but you seem to miss how its supposed to be. the regular package is the latest variant and if you need anything but the newest you introduce a specially named one with a pinned version, like ruby-unf0.1.
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.
Comment by Eli Schwartz (eschwartz) - Monday, 27 January 2020, 17:23 GMT
If version 0.2.0 was stable, but software required a pinned version constraint on only version 0.1.x, then would we all agree that this package is fine and other packages must depend on a specially named, pinned pacman package providing the old version?

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.
Comment by Anatol Pomozov (anatolik) - Monday, 27 January 2020, 18:04 GMT
0.1.4 is not the old version. It is the default stable version. 0.2.0.beta2 is the unreleased beta version and not used by gem (unless explicitly specified).

unreleased beta (non-default) versions need to be slotted instead.
Comment by Levente Polyak (anthraxx) - Monday, 27 January 2020, 18:35 GMT
Anatol, we are now going full rounds in a circle. read what i wrote about Arch pacman naming standards and don't ignore it just because 'ruby ruby ruby'
Comment by Erich Eckner (deepthought) - Monday, 27 January 2020, 19:32 GMT
This sounds similar to having a $pkgname and a $pkgname-git package.
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)
Comment by Anatol Pomozov (anatolik) - Thursday, 30 January 2020, 01:32 GMT
> This sounds similar to having a $pkgname and a $pkgname-git package.

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

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

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.
Comment by Levente Polyak (anthraxx) - Thursday, 30 January 2020, 08:32 GMT
Which again is no different from python, in fact in python land its potentially even more dramatic as you can only have a single version installed at the same time.

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

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 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.
Comment by Christian Rebischke (Shibumi) - Thursday, 30 January 2020, 12:24 GMT
I think I've mentioned this already in IRC, but for transparency (@anatolik):

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.

Comment by Eli Schwartz (eschwartz) - Friday, 31 January 2020, 15:20 GMT
anatolik, please remove the ruby-unf-beta package you YOLO uploaded despite multiple people across both the TU and Dev groups disputing the validity of such a move. It should not be uploaded unless consensus is reached, or else as a last resort in a fight to the death... Have we reached that stage already?
Comment by Toolybird (Toolybird) - Sunday, 30 April 2023, 22:31 GMT
IIUC, this is no longer an issue and/or has been worked around. Proposing closure unless someone pipes up.