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

Attachment: signature.asc
Description: PGP signature

Reply via email to