You are not logged in.
I released a package to AUR (ruby-roo), and it seems to be working correctly.
However, I often encountered problems with AUR-based ruby gem packages when Ruby was updated to next major version (e.g. from 2.3 to 2.4, from 2.4 to 2.5), because files in the package contain hardcoded ruby version in the path:
/usr/lib/ruby/gems/2.6.0/gems/roo-2.8.0/lib/
/usr/lib/ruby/gems/2.6.0/gems/roo-2.8.0/lib/roo.rb
/usr/lib/ruby/gems/2.6.0/gems/roo-2.8.0/lib/roo/
/usr/lib/ruby/gems/2.6.0/gems/roo-2.8.0/lib/roo/base.rb
/usr/lib/ruby/gems/2.6.0/gems/roo-2.8.0/lib/roo/constants.rb
When Ruby version will be updated to 2.7.0, users' applications will not be able to find the gem.
How can I as a maintainer fix this problem?
If I hardcode Ruby version in the dependencies, then users will be unable to install new package until I manually change the dependency.
Last edited by Rogach (2019-01-19 13:33:36)
Offline
Welcome to the arch linux forums Rogach.
Updating AUR packages when dependencies are updated is the responsibility of the user.
Offline
Ok. Will it be acceptable to bump pkgrel when dependency was updated in such a breaking way, to indicate that rebuild is required?
Offline
You could check on aur-general mailing list to be certain but I have seen other packages using the practice but I have no idea how common it is.
Offline
It's up to the individual AUR package maintainers.
Some people bump the pkgrel in such events, but in my opinion that encourages laziness and penalises the consumers of the package who already rebuilt it following the breakage (they now have to rebuild it again, for no benefit other than to get the new pkgrel). Also, if users notice the AUR package update before they update the rest of their system, they may end up with the same problem anyway (update AUR package outside of a clean chroot -> then `pacman -Syu` -> results in a broken AUR package).
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
It's up to the individual AUR package maintainers.
Some people bump the pkgrel in such events, but in my opinion that encourages laziness and penalises the consumers of the package who already rebuilt it following the breakage (they now have to rebuild it again, for no benefit other than to get the new pkgrel).
-_- I'm usually a lot faster when bumping pkgrel than users are at rebuilding. If not, I typically don't bother with the pkgver bump.
Also, if users notice the AUR package update before they update the rest of their system, they may end up with the same problem anyway (update AUR package outside of a clean chroot -> then `pacman -Syu` -> results in a broken AUR package).
As an AUR maintainer, I don't wish to support people who update their AUR packages without updating their official repository packages first. YMMV.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Oh yeah, those users have nobody to blame but themselves, but the point I was trying to make is that the AUR has too many variables outside of a package maintainers control. It isn't a binary repository, pkgrel bumps are of questionable value.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I think I agree with eschwarts on both points, and will go with bumping pkgrel fast enough (I have notifications set up, so that should happen really quickly after new releases). Thanks!
Offline