On Sun, 2023-03-26 at 21:39 +0000, Robin H. Johnson wrote:
> On Sun, Mar 26, 2023 at 09:57:36AM +0200, Hans de Graaff wrote:
> > # Hans de Graaff <gra...@gentoo.org> (2023-03-26)
> > # Mask ruby27-only packages related to hiera-eyaml. These require a
> > now
> > # masked version of puppet and other obsolete ruby27-only test
> > # dependencies. Masked for removal on 2023-04-26.
> > dev-ruby/hiera-eyaml
> > dev-ruby/hiera-eyaml-gpg
> Infra needs these, please revert.
> I can confirm that the package does work properly with both Ruby 3.0 &
> Ruby 3.1
> The Puppet/Aruba/Cucumber deps are test-only.
> Looking deeper, I think the <puppet-6 dep is wrong, because upstream
> CI
> tests on Ruby 3.1 + Puppet7 already successfully. The Gemfile doesn't
> lock in old Puppet either.
> https://github.com/voxpupuli/hiera-eyaml/actions/runs/4280324437/jobs/7451960271
> The same CI run *also* shows aruba-0.6.2 installed on Ruby 3.2, and
> used
> to test hiera-eyaml (hiera-eyaml has a tiny patch in master for Ruby
> 3.2
> support).
> Lastly, if I tweak aruba-0.6.2 and install it for Ruby 3.0 & Ruby 3.1
> myself without FEATURES=tests on aruba, then the tests on hiera-eyaml
> &
> hiera-eyaml-gpg ALSO pass.
> So do we really remove packages because a 2nd-order test-only
> dependency
> fails it's own tests? (aruba:0 failing tests on Ruby 3 being the only
> reason I can see to remove stuff right now).

There's a pattern here of infra or packages added for infra rotting with
unattended bugs or otherwise not meeting modern standards and then panic
at the 11th hour when they're last-rited.

Python and Ruby packages especially *need* tests because of how brittle
they are. An import can break because of a new or changed dependency,
for example.

Instead of asking graaff to revert it, you should fix the package to
work with modern Ruby implementations and get either its tests in full
or a subset of its tests running (with a comment in the ebuild
explaining the situation).

It is _critical_ that we get into ruby31 or newer ASAP and graaff is
doing hard work to get us there, especially because of the upcoming
openssl EOL. Unmasking this would mean we have to keep ruby27 around for
longer and can't focus efforts on newer Ruby.

Reply via email to