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/