Please add versions to std gems provided by ruby package.
Description:
Similar to how perl is doing. Sometimes other gems (or rather AUR packages thereof) have versions constraints. I did not find anything in the wild yet, but it doesn't seem improbable that this could cause some issues.
Additional info:
- package version: 3.2.4
- config and/or log files: N/A
- link to upstream bug report: N/A
Activity
added priority3-normal severity4-low statusunconfirmed labels
assigned to @freswa, @toolybird, and @gromit
I actually "want" to make this a problem.
I found a package that doesn't depend on versioned dependency and doesn't work, ruby-selenium-webdriver, see my comment there. What I wanted to do is to upload ruby-base64 package to AUR. ruby-selenium-webdriver should then depend on
ruby-base64>=0.2. In case of ruby-3.2.4, separate package would need to be installed, when extra/ruby will get bumped to 3.3.0, then it would provideruby-base64=0.2.0and it wouldn't require installation of extra package.added scopequestion statusconfirmed labels and removed statusunconfirmed label
assigned to @anatolik, @bastelfreak, and @segaja and unassigned @freswa, @toolybird, and @gromit
Oh, this would also require to remove conflicts and replaces. Seeing that it was recent change I don't think it's that good idea. It could be solved by having versions in conflicts and replaces too so that it only affects the older "pre ruby 3.2" versions, but this would create even bigger mess.
Thank you very much for your input here. I don't think this complexity makes much sense to maintain, especially for support pre 3.2 versions in the AUR which are considered end-of-life anyway. I'd say this is a wont-fix as the maintenance burden would be quite high to manage this. You should implicitly be able to achieve this by using version constraints via the ruby version itself, which essentially is pulling in these stdgems.
I think there's a misunderstanding on what I meant by older ruby version. I will try to explain:
- In the past I had installed ruby 3.0.6, ruby-base64 was separate package and I could myself use newer version if needed.
- Update from 3.0.6 to (current repos) 3.2.4, pacman prompts to replace many gems as they are provided by ruby. ruby-base64 now conflicts, so I can't install this package if I needed newer version.
- Finally, by older versions I meant to conflicts & replaces with ruby-base64 <0.1.1-5 (the old separate package). These conflicts/replaces versions don't need to be changed.
In 3. the old versions are conflicts/replaces, but it doesn't hinder anyone who wants to install newer versions of these gems for some reason. Similar "pkgver based conflicts" approach was done in mkinitcpio for some time:
Added in: mkinitcpio@2457b758
Removed in: mkinitcpio@7edc62c9You should implicitly be able to achieve this by using version constraints via the ruby version itself, which essentially is pulling in these stdgems.
This doesn't really work, as example I will use selenium-webdriver. It requires ruby>= 3.0, but it also requires base64 ~> 0.2, which is only included in stdgems in ruby 3.3.0.
Alternative to 3, is to just remove conflicts/replaces from ruby package now, but this would create problems, because it wasn't that long since this package change and if these would be removed, it would cause problems for some people who don't upgrade systems often.
I hope this is more clear now.
mentioned in merge request !6
unassigned @anatolik
I agree with @anthraxx that this is a wont fix. If there is a conflict defined by the
rubypackage than this is by design as ruby has relatively strict constraints between the ruby version and the default gems it ships. There is no guarantee that any newer version then they ship will actually work and upstream gems don't expect such "drifts".
