default gems in ruby deployment
Hello everyone, | | | || while trying to package the ruby framework rails [0] I stumbled over the fact that ruby itself is shipping an assortment of "default gems" which they call "Standard Library" [1] [2] || and something called "Bundled Gems" [3], which is another set of "default gems". || The problem I see in these gems is that they are pulled into the ruby source repo [4] from their dedicated original sources before a ruby release and then get used in the release. || Furthermore ruby itself does not release a new version of itself whenever a gem of this standard library updates, which means that over time sooner or later most of these gems in the bundle || will be out-of-date. || Now apparently ruby has a general solution for that. You can have multiple versions of one gem installed, the "default" versions do show up with a default prefix in the `gem list` output. || | | || So much for the actual ruby state. Now I would like to highlight some points I found out about how Arch Linux is packaging ruby and the issues I see with it. || | | || Our ruby package [5] is currently removing a total of nine pre-shipped gems from the main ruby release with the comment that they are shipped in seperate packages [6]. || I recently checked and found out that three of these removed gems are not provided as packages (anymore?). Namely rbs, typerof and erb. || Furthermore the PKGBUILD has code in there which states that it removes *all* bundled gems to avoid conflicts [7], but when I run a `gem list | grep 'default'` I still see the default gems. || After some research I found out the reason is because the path in which the default gems are located are not the path that we are removing with these three lines of code. || It could be that the location of these default gems changed in some version and was never updated. || | | || The problem I see in the current situation is that we have most of the default gems still installed and then some of them get upgraded (sometimes even to a higher major version) by dedicated packages. || This can potentially break dependency changes if one of the not upgraded default gems is requiring the gem that was upgraded to a new major version. || | | || From my point of view the only real fix for this is to make sure that we again remove all the default gems so that they can be packaged seperatly. Whether or not we want to provide all gems from the || "standard library" and "bundled gems" is then a different question and would in the end require more ruby packages. || Also I would recomment to add a comment to the PKGBUILD file of these gems stating that they are part of the "standard library" / "bundled gems" and such shouldn't be dropped from the repos in the future. || | | || We also could think about putting all the "standard library" gems (and maybe even the "bundled gems") in a package group called "ruby-stdlib" or a meta-package (which I think is better). || That way users could easily install all of them with one command and we also know which packages belong to the "ruby standard library". || | | || One side effect I see with this approach is that we currently have "hidden dependencies" on some of the standard library gems like in case of ruby-nokogiri [8], which is depending on ruby-racc which is not listed in the PKGBUILD file. || Currently this package only works because racc is one of the gems in the standard library [9] and such pre-installed. If we now cleanup the ruby package we need to fix such issues. || | | || | | || Best regards || Segaja || | | || | | || [0] https://rubyonrails.org/ || [1] https://rubyreferences.github.io/rubyref/stdlib.html || [2] https://ruby-doc.org/stdlib-3.1.2/ || [3] https://rubyreferences.github.io/rubyref/stdlib/bundled.html || [4] https://github.com/ruby/ruby/tree/master/lib || [5] https://archlinux.org/packages/extra/x86_64/ruby/ || [6] https://github.com/archlinux/svntogit-packages/blob/packages/ruby/trunk/PKGB... || [7] https://github.com/archlinux/svntogit-packages/blob/packages/ruby/trunk/PKGB... || [8] https://bugs.archlinux.org/task/71500 ||[9] https://rubyreferences.github.io/rubyref/stdlib/string-utilities/racc.html|
Hello Andreas Thank you for your research. The standard gems are indeed a source of confusion both in Ruby distribution and in Arch packages. One thing that could really help here is a working proposal with a patch to PKGBUILD. If you can come up with one please file an arch bug and share it with me so I can look at it. On Wed, Jun 1, 2022 at 10:45 AM Andreas 'Segaja' Schleifer < segaja@archlinux.org> wrote:
Hello everyone,
while trying to package the ruby framework rails [0] I stumbled over the fact that ruby itself is shipping an assortment of "default gems" which they call "Standard Library" [1] [2] and something called "Bundled Gems" [3], which is another set of "default gems". The problem I see in these gems is that they are pulled into the ruby source repo [4] from their dedicated original sources before a ruby release and then get used in the release. Furthermore ruby itself does not release a new version of itself whenever a gem of this standard library updates, which means that over time sooner or later most of these gems in the bundle will be out-of-date. Now apparently ruby has a general solution for that. You can have multiple versions of one gem installed, the "default" versions do show up with a default prefix in the `gem list` output.
So much for the actual ruby state. Now I would like to highlight some points I found out about how Arch Linux is packaging ruby and the issues I see with it.
Our ruby package [5] is currently removing a total of nine pre-shipped gems from the main ruby release with the comment that they are shipped in seperate packages [6]. I recently checked and found out that three of these removed gems are not provided as packages (anymore?). Namely rbs, typerof and erb. Furthermore the PKGBUILD has code in there which states that it removes *all* bundled gems to avoid conflicts [7], but when I run a `gem list | grep 'default'` I still see the default gems. After some research I found out the reason is because the path in which the default gems are located are not the path that we are removing with these three lines of code. It could be that the location of these default gems changed in some version and was never updated.
The problem I see in the current situation is that we have most of the default gems still installed and then some of them get upgraded (sometimes even to a higher major version) by dedicated packages. This can potentially break dependency changes if one of the not upgraded default gems is requiring the gem that was upgraded to a new major version.
From my point of view the only real fix for this is to make sure that we again remove all the default gems so that they can be packaged seperatly. Whether or not we want to provide all gems from the "standard library" and "bundled gems" is then a different question and would in the end require more ruby packages. Also I would recomment to add a comment to the PKGBUILD file of these gems stating that they are part of the "standard library" / "bundled gems" and such shouldn't be dropped from the repos in the future.
We also could think about putting all the "standard library" gems (and maybe even the "bundled gems") in a package group called "ruby-stdlib" or a meta-package (which I think is better). That way users could easily install all of them with one command and we also know which packages belong to the "ruby standard library".
One side effect I see with this approach is that we currently have "hidden dependencies" on some of the standard library gems like in case of ruby-nokogiri [8], which is depending on ruby-racc which is not listed in the PKGBUILD file. Currently this package only works because racc is one of the gems in the standard library [9] and such pre-installed. If we now cleanup the ruby package we need to fix such issues.
Best regards Segaja
[0] https://rubyonrails.org/ [1] https://rubyreferences.github.io/rubyref/stdlib.html [2] https://ruby-doc.org/stdlib-3.1.2/ [3] https://rubyreferences.github.io/rubyref/stdlib/bundled.html [4] https://github.com/ruby/ruby/tree/master/lib [5] https://archlinux.org/packages/extra/x86_64/ruby/ [6] https://github.com/archlinux/svntogit-packages/blob/packages/ruby/trunk/PKGB... [7] https://github.com/archlinux/svntogit-packages/blob/packages/ruby/trunk/PKGB... [8] https://bugs.archlinux.org/task/71500 [9] https://rubyreferences.github.io/rubyref/stdlib/string-utilities/racc.html
On 6/1/22 20:31, Anatol Pomozov wrote:
Hello Andreas
Thank you for your research.
The standard gems are indeed a source of confusion both in Ruby distribution and in Arch packages.
One thing that could really help here is a working proposal with a patch to PKGBUILD. If you can come up with one please file an arch bug and share it with me so I can look at it.
Hi again, The problem is that in order to get this fully working we need to package all 74 stdlib ruby gems. Currently we have only packaged 9 of them from which 5 are in the AUR. My proposal to get this into a working state are these steps: - remove all gems from the ruby package which are already packaged as dedicated packages in [extra] or [community] - create a ruby-stdlib meta package which requires the existing ruby stdlib packages - make the ruby package require the new ruby-stdlib package These steps should clear up the situation for the few existing separate builds of the stdlib packages. Then we can successively package the other stdlib packages and once one is done remove it from the ruby package and add it as dependency to the ruby-stdlib package. Next week I can prepare the ruby-stdlib package and a patch to the ruby package to get the first steps of this plan working. Best regards Segaja
Hi! On 01.06.22 23:05, Andreas 'Segaja' Schleifer wrote:
On 6/1/22 20:31, Anatol Pomozov wrote:
Hello Andreas
Thank you for your research.
The standard gems are indeed a source of confusion both in Ruby distribution and in Arch packages.
One thing that could really help here is a working proposal with a patch to PKGBUILD. If you can come up with one please file an arch bug and share it with me so I can look at it.
Hi again,
The problem is that in order to get this fully working we need to package all 74 stdlib ruby gems. Currently we have only packaged 9 of them from which 5 are in the AUR.
My proposal to get this into a working state are these steps:
- remove all gems from the ruby package which are already packaged as dedicated packages in [extra] or [community] - create a ruby-stdlib meta package which requires the existing ruby stdlib packages - make the ruby package require the new ruby-stdlib package
I talked to Segaja about this a lot on IRC before he submitted it to the ML. I think this is a very good approach to fix our slightly broken Ruby ecosystem. I also think that the ruby PKGBUILD should be updated before the Ruby 3.1 Rebuild. I'm happy to help packaging the stdlib gems. Cheers, Tim
These steps should clear up the situation for the few existing separate builds of the stdlib packages. Then we can successively package the other stdlib packages and once one is done remove it from the ruby package and add it as dependency to the ruby-stdlib package.
Next week I can prepare the ruby-stdlib package and a patch to the ruby package to get the first steps of this plan working.
Best regards Segaja
Hi Andreas, first off: Thanks for looking into this! I guess not all of the packagers knows how complicated and time-consuming packaging ruby can be. On 2022-06-01 23:05:45 (+0200), Andreas 'Segaja' Schleifer wrote:
The problem is that in order to get this fully working we need to package all 74 stdlib ruby gems. Currently we have only packaged 9 of them from which 5 are in the AUR.
If you have created a list somewhere and if I have some spare time, I'd be glad to help package some.
My proposal to get this into a working state are these steps:
- remove all gems from the ruby package which are already packaged as dedicated packages in [extra] or [community] - create a ruby-stdlib meta package which requires the existing ruby stdlib packages - make the ruby package require the new ruby-stdlib package
These steps should clear up the situation for the few existing separate builds of the stdlib packages. Then we can successively package the other stdlib packages and once one is done remove it from the ruby package and add it as dependency to the ruby-stdlib package.
Next week I can prepare the ruby-stdlib package and a patch to the ruby package to get the first steps of this plan working.
As the ruby sources will drag in the vendored dependencies it could prove beneficial to have ruby's PKGBUILD carry ruby-stdlib as a split package (unless you think that complicates things). That way it is easy to determine if a new vendored dep is added or removed as well. Best, David -- https://sleepmap.de
On 6/14/22 10:17, David Runge wrote:
Hi Andreas,
first off: Thanks for looking into this! I guess not all of the packagers knows how complicated and time-consuming packaging ruby can be.
On 2022-06-01 23:05:45 (+0200), Andreas 'Segaja' Schleifer wrote:
The problem is that in order to get this fully working we need to package all 74 stdlib ruby gems. Currently we have only packaged 9 of them from which 5 are in the AUR.
If you have created a list somewhere and if I have some spare time, I'd be glad to help package some.
My proposal to get this into a working state are these steps:
- remove all gems from the ruby package which are already packaged as dedicated packages in [extra] or [community] - create a ruby-stdlib meta package which requires the existing ruby stdlib packages - make the ruby package require the new ruby-stdlib package
These steps should clear up the situation for the few existing separate builds of the stdlib packages. Then we can successively package the other stdlib packages and once one is done remove it from the ruby package and add it as dependency to the ruby-stdlib package.
Next week I can prepare the ruby-stdlib package and a patch to the ruby package to get the first steps of this plan working.
As the ruby sources will drag in the vendored dependencies it could prove beneficial to have ruby's PKGBUILD carry ruby-stdlib as a split package (unless you think that complicates things). That way it is easy to determine if a new vendored dep is added or removed as well.
Best, David
Hello everyone, thanks for the words of support. Once we agree on a way to go I can generate some kind of TODO list (not in archweb) so that we know what we need to do. Also I would recommend that any new packaged gems should be source builds and if possible have tests enabled. As to the state of things and a patch for the PKGBUILD: I have a diff of the ruby PKGBUILD ready [0]. I’m adding another split package to the mix called ruby-stdlib which is defining the dependencies we already have. Furthermore I’m removing the stdlib gem from the base ruby package which we already have as a dedicated package. In the end we need to do this for all of the stdlib and bundled gems once they are packaged. Afterwards we can simplify the cleanup logic that happens in `package_ruby()` again. One more point I would like to bring up is that currently the ruby package [1] only has one maintainer (Anatol) and I think we should increase the bus factor for this package. I don’t consider myself an expert for ruby packaging, but I would be happy to help out. The only problem is that the package is currently located in [extra] where I don’t have write permissions to as a TU. What would be the effort / impact of moving this package (and other related ruby packages) to [community] to have more people (maybe also David or Tim) maintain it? We also should update the comments at the beginning of the PKGBUILD file, as it currently only lists people as “Contributor” and no one as “Maintainer”. Best regards Segaja [0] https://paste.xinu.at/Fve7R/ [1] https://archlinux.org/packages/extra/x86_64/ruby/
Hi, On 14.06.22 21:18, Andreas 'Segaja' Schleifer wrote:
On 6/14/22 10:17, David Runge wrote:
Hi Andreas,
first off: Thanks for looking into this! I guess not all of the packagers knows how complicated and time-consuming packaging ruby can be.
On 2022-06-01 23:05:45 (+0200), Andreas 'Segaja' Schleifer wrote:
The problem is that in order to get this fully working we need to package all 74 stdlib ruby gems. Currently we have only packaged 9 of them from which 5 are in the AUR.
If you have created a list somewhere and if I have some spare time, I'd be glad to help package some.
My proposal to get this into a working state are these steps:
- remove all gems from the ruby package which are already packaged as dedicated packages in [extra] or [community] - create a ruby-stdlib meta package which requires the existing ruby stdlib packages - make the ruby package require the new ruby-stdlib package
These steps should clear up the situation for the few existing separate builds of the stdlib packages. Then we can successively package the other stdlib packages and once one is done remove it from the ruby package and add it as dependency to the ruby-stdlib package.
Next week I can prepare the ruby-stdlib package and a patch to the ruby package to get the first steps of this plan working.
As the ruby sources will drag in the vendored dependencies it could prove beneficial to have ruby's PKGBUILD carry ruby-stdlib as a split package (unless you think that complicates things). That way it is easy to determine if a new vendored dep is added or removed as well.
Best, David
Hello everyone,
thanks for the words of support. Once we agree on a way to go I can generate some kind of TODO list (not in archweb) so that we know what we need to do. Also I would recommend that any new packaged gems should be source builds and if possible have tests enabled.
I highly agree with this. We should move away from downloading blobs from rubygems.org.
As to the state of things and a patch for the PKGBUILD:
I have a diff of the ruby PKGBUILD ready [0]. I’m adding another split package to the mix called ruby-stdlib which is defining the dependencies we already have. Furthermore I’m removing the stdlib gem from the base ruby package which we already have as a dedicated package.
In the end we need to do this for all of the stdlib and bundled gems once they are packaged. Afterwards we can simplify the cleanup logic that happens in `package_ruby()` again.
sounds good to me.
One more point I would like to bring up is that currently the ruby package [1] only has one maintainer (Anatol) and I think we should increase the bus factor for this package. I don’t consider myself an expert for ruby packaging, but I would be happy to help out. The only problem is that the package is currently located in [extra] where I don’t have write permissions to as a TU. What would be the effort / impact of moving this package (and other related ruby packages) to [community] to have more people (maybe also David or Tim) maintain it?
As mentioned on IRC: I'm happy to help out and I think it would be good for our package quality if more people could work on the Ruby package. If that means it needs to be moved to community I'm +1 for the idea (not that I could decide this).
We also should update the comments at the beginning of the PKGBUILD file, as it currently only lists people as “Contributor” and no one as “Maintainer”.
Best regards Segaja
[0] https://paste.xinu.at/Fve7R/ [1] https://archlinux.org/packages/extra/x86_64/ruby/
Hi On Sun, Jun 19, 2022 at 8:43 AM Tim Meusel <tim@bastelfreak.de> wrote:
Hi,
On 14.06.22 21:18, Andreas 'Segaja' Schleifer wrote:
On 6/14/22 10:17, David Runge wrote:
Hi Andreas,
first off: Thanks for looking into this! I guess not all of the packagers knows how complicated and time-consuming packaging ruby can be.
On 2022-06-01 23:05:45 (+0200), Andreas 'Segaja' Schleifer wrote:
The problem is that in order to get this fully working we need to package all 74 stdlib ruby gems. Currently we have only packaged 9 of them from which 5 are in the AUR.
If you have created a list somewhere and if I have some spare time, I'd be glad to help package some.
My proposal to get this into a working state are these steps:
- remove all gems from the ruby package which are already packaged as dedicated packages in [extra] or [community] - create a ruby-stdlib meta package which requires the existing ruby stdlib packages - make the ruby package require the new ruby-stdlib package
These steps should clear up the situation for the few existing separate builds of the stdlib packages. Then we can successively package the other stdlib packages and once one is done remove it from the ruby package and add it as dependency to the ruby-stdlib package.
Next week I can prepare the ruby-stdlib package and a patch to the ruby package to get the first steps of this plan working.
As the ruby sources will drag in the vendored dependencies it could prove beneficial to have ruby's PKGBUILD carry ruby-stdlib as a split package (unless you think that complicates things). That way it is easy to determine if a new vendored dep is added or removed as well.
Best, David
Hello everyone,
thanks for the words of support. Once we agree on a way to go I can generate some kind of TODO list (not in archweb) so that we know what we need to do. Also I would recommend that any new packaged gems should be source builds and if possible have tests enabled.
I highly agree with this. We should move away from downloading blobs from rubygems.org.
A bit of clarification here. gem files distributed via rubygems are *source* packages. It includes ruby/C/Makefiles/... that are compiled into binary blobs at the user side. Rubygems.org also allows the distribution of binary platform-specific packages (when ":platform" is set) but it is rarely used in practice.
As to the state of things and a patch for the PKGBUILD:
I have a diff of the ruby PKGBUILD ready [0]. I’m adding another split package to the mix called ruby-stdlib which is defining the dependencies we already have. Furthermore I’m removing the stdlib gem from the base ruby package which we already have as a dedicated package.
In the end we need to do this for all of the stdlib and bundled gems once they are packaged. Afterwards we can simplify the cleanup logic that happens in `package_ruby()` again.
sounds good to me.
One more point I would like to bring up is that currently the ruby package [1] only has one maintainer (Anatol) and I think we should increase the bus factor for this package. I don’t consider myself an expert for ruby packaging, but I would be happy to help out. The only problem is that the package is currently located in [extra] where I don’t have write permissions to as a TU. What would be the effort / impact of moving this package (and other related ruby packages) to [community] to have more people (maybe also David or Tim) maintain it?
As mentioned on IRC: I'm happy to help out and I think it would be good for our package quality if more people could work on the Ruby package. If that means it needs to be moved to community I'm +1 for the idea (not that I could decide this).
We also should update the comments at the beginning of the PKGBUILD file, as it currently only lists people as “Contributor” and no one as “Maintainer”.
Best regards Segaja
[0] https://paste.xinu.at/Fve7R/ [1] https://archlinux.org/packages/extra/x86_64/ruby/
Hi all, sorry for the late reply. On 2022-06-14 21:18:18 (+0200), Andreas 'Segaja' Schleifer wrote:
As to the state of things and a patch for the PKGBUILD:
I have a diff of the ruby PKGBUILD ready [0]. I’m adding another split package to the mix called ruby-stdlib which is defining the dependencies we already have. Furthermore I’m removing the stdlib gem from the base ruby package which we already have as a dedicated package.
In the end we need to do this for all of the stdlib and bundled gems once they are packaged. Afterwards we can simplify the cleanup logic that happens in `package_ruby()` again.
This looks good and seems like a reasonable way forward! Let's proceed!
One more point I would like to bring up is that currently the ruby package [1] only has one maintainer (Anatol) and I think we should increase the bus factor for this package. I don’t consider myself an expert for ruby packaging, but I would be happy to help out. The only problem is that the package is currently located in [extra] where I don’t have write permissions to as a TU. What would be the effort / impact of moving this package (and other related ruby packages) to [community] to have more people (maybe also David or Tim) maintain it? We also should update the comments at the beginning of the PKGBUILD file, as it currently only lists people as “Contributor” and no one as “Maintainer”.
Ruby does not seem to be directly required by anything in extra. E.g. apparmor only carries it as an optional dependency. So moving should not be an issue. @anatol what do you think? I agree that a higher bus factor on this package would be very good, but I also do not count myself as a ruby expert. If it proves impossible to move ruby to [community], I would volunteer to co-maintain to help implement the upcoming changes, but I'd much rather see this done by Tim and Andreas, who have been spending quite some time on improving the quality of many ruby packages already. Somewhat related, I'd love to see the respective package guidelines [a] be updated, so that they reflect a workflow in which packages are built from source tarballs, tests are run and unreproducible files are removed. This way we can guarantee a higher degree of functionality to the user and easily detect breakage on rebuilds, while having reproducible packages. Best, David [a] https://wiki.archlinux.org/title/Ruby_Gem_package_guidelines -- https://sleepmap.de
On 2022-06-24 22:47:04 (+0200), David Runge wrote:
Ruby does not seem to be directly required by anything in extra. E.g. apparmor only carries it as an optional dependency. So moving should not be an issue. @anatol what do you think?
As there has been no negative feedback to this suggestion, I'd move ruby and rubygems to [community] tomorrow, so that work on the topic can commence. Best, David -- https://sleepmap.de
On 2022-07-02 13:07:38 (+0200), David Runge wrote:
As there has been no negative feedback to this suggestion, I'd move ruby and rubygems to [community] tomorrow, so that work on the topic can commence.
The packages are now moved and the updated package guidelines are in place: https://wiki.archlinux.org/title/Ruby_package_guidelines Best, David -- https://sleepmap.de
On 7/8/22 10:44, David Runge wrote:
On 2022-07-02 13:07:38 (+0200), David Runge wrote:
As there has been no negative feedback to this suggestion, I'd move ruby and rubygems to [community] tomorrow, so that work on the topic can commence.
The packages are now moved and the updated package guidelines are in place: https://wiki.archlinux.org/title/Ruby_package_guidelines
Best, David
Hello again, First of all I would like to thank David for moving the packages. Furthermore I want to thank David and Tim for the very constructive session to create the new Ruby package guidelines [0]. I loved the session and hope we can do similar cooperative work in the future. While doing research to generate some kind of TODO list for the next tasks I had a deeper look into the entire situation and found out some points were i was wrong: - Previously I assumed that “stdlib” and “bundled gems” are kind of the same thing. This was a misconception. - In fact “bundled gems” are actually just what the name suggests: They are .gem files just thrown into the release archive of the ruby release. This means that our package never cared about them. - The package `rubygems` is somehow differently bundled with the ruby package and actually neither part of the “stdlib” nor the “bundled gems” As a result of these “errors” I ended up creating yet another split meta package called `ruby-bundledgems` as the ruby bundled gems documentation [1] states that they should be installed on any system where ruby is installed. I updated the diff for `ruby` [2] to reflect the above points. If there are no objections to this diff I would apply it and push it to [community-testing] to see if there are any issues. As you can see I already listed all the stdlib and bundled gems that we need in the end in the updated PKGBUILD and commented out the ones we don’t have in the repos yet. Furthermore I already took a look into ruby 3.1.2 and listed the changes for stdlib and bundled gems in comments in these packages. Lastly I talked to Tim and we agreed to also jump in to co-maintain the ruby package in order to reduce the bus factor. I hope this is okay with you, Anatol. In anticipation that it would be, I already updated the PKGBUILD maintainer comments at the beginning of the file. Best regards Andreas [0] https://wiki.archlinux.org/title/Ruby_package_guidelines [1] https://rubyreferences.github.io/rubyref/stdlib/bundled.html [2] https://paste.xinu.at/EF6dlx/
Hello, I have applied my patch and pushed the changes to [community-testing]. It would be nice if some people could test it and report back to me. If anyone has any points what we still should change in the package then please voice them. Best regards Andreas
Hi, I did some testing with the new packages, everything worked fine. I think we're fine moving them to Community. Cheers, Tim On 13.07.22 22:57, Andreas 'Segaja' Schleifer wrote:
Hello,
I have applied my patch and pushed the changes to [community-testing].
It would be nice if some people could test it and report back to me.
If anyone has any points what we still should change in the package then please voice them.
Best regards Andreas
Hi Thanks for the cleanup. The ruby itself works fine. I have a few minor notes though. I see some packages (e.g. https://github.com/archlinux/svntogit-community/blob/packages/ruby-rexml/tru...) use gem tool during install() phase but the dependency is not specified in the dependency list. It needs to be fixed. The installation process gives numerous warnings about cyclic dependencies though. One question with cyclic dependencies is how the update is handled for them. Let's say we want to update ruby to 3.1 - what update sequence needs to be used here? log: warning: dependency cycle detected: warning: ruby-json will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-minitest will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-power_assert will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-test-unit will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-bundledgems will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-bundledgems will be installed before its ruby dependency On Wed, Jul 13, 2022 at 1:57 PM Andreas 'Segaja' Schleifer < segaja@archlinux.org> wrote:
Hello,
I have applied my patch and pushed the changes to [community-testing].
It would be nice if some people could test it and report back to me.
If anyone has any points what we still should change in the package then please voice them.
Best regards Andreas
Hello On 7/16/22 18:02, Anatol Pomozov wrote:
Hi
Thanks for the cleanup. The ruby itself works fine. I have a few minor notes though.
I see some packages (e.g. https://github.com/archlinux/svntogit-community/blob/packages/ruby-rexml/tru... <https://github.com/archlinux/svntogit-community/blob/packages/ruby-rexml/trunk/PKGBUILD>) use gem tool during install() phase but the dependency is not specified in the dependency list. It needs to be fixed.
I guess that is in theory an issue of all our ruby packages, since they use `gem`, which is part of the `rubygems` package. But since I didn't touch the rubygems package this error was already present in the past. In theory we would have to fix that, but since rubygems is still a dependency for ruby, the `gem` binary will always be there when you install the ruby package. Btw, https://bugs.archlinux.org/task/71500 is a similar case where a package in theory depends on a stdlib, which for now is shipped with ruby but in the future will be its own package. But again it will be a dependency to the ruby package so in practice this doesn't break anything as far as I understand.
The installation process gives numerous warnings about cyclic dependencies though. One question with cyclic dependencies is how the update is handled for them. Let's say we want to update ruby to 3.1 - what update sequence needs to be used here?
log: warning: dependency cycle detected: warning: ruby-json will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-stdlib will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-minitest will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-power_assert will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-test-unit will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-bundledgems will be installed before its ruby dependency warning: dependency cycle detected: warning: ruby-bundledgems will be installed before its ruby dependency
I also saw these and I'm not 100% sure about them. In the end the amount of them will only increase when we package more stdlib gems. In theory we could remove the `ruby` dependency from the other packages, but that wouldn't really mirror the actual situation. As for upgrading: I never thought about it on that level to be honest. But any upgrade (like ruby 3.1) would have to happen on testing anyway and I can imagine this might involve some PKGBUILD edits before to get `ruby` rebuild in 3.1 and then push that to [community-testing]. Afterwards rebuild the stdlib packages to 3.1 and then re-add the dependency in the ruby package. Not sure if that answers your question. Best regards Andreas
On 7/13/22 22:57, Andreas 'Segaja' Schleifer wrote:
Hello,
I have applied my patch and pushed the changes to [community-testing].
It would be nice if some people could test it and report back to me.
If anyone has any points what we still should change in the package then please voice them.
Best regards Andreas
As some of you might have already noticed these changes were moved from [community-testing] to [community] today. Furthermore I created a markdown TODO list for the ruby stdlib gems that now need to be packaged: https://md.archlinux.org/s/yIrv6T-Gm# I will start on that list in the next days. If anyone would like to help it would be highly appreciated. Please read the Markdown link for further steps. Best regards Segaja
participants (4)
-
Anatol Pomozov
-
Andreas 'Segaja' Schleifer
-
David Runge
-
Tim Meusel