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/
OpenPGP_signature
Description: OpenPGP digital signature
