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/
>