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