Mailing List Archive

Last rites: dev-ruby/hiera-eyaml and dev-ruby/hiera-eyaml-gpg
# Hans de Graaff <graaff@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
Re: Last rites: dev-ruby/hiera-eyaml and dev-ruby/hiera-eyaml-gpg [ In reply to ]
On Sun, Mar 26, 2023 at 09:57:36AM +0200, Hans de Graaff wrote:
> # Hans de Graaff <graaff@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).

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: Last rites: dev-ruby/hiera-eyaml and dev-ruby/hiera-eyaml-gpg [ In reply to ]
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 <graaff@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.
Re: Last rites: dev-ruby/hiera-eyaml and dev-ruby/hiera-eyaml-gpg [ In reply to ]
On Sun, Mar 26, 2023 at 11:57:00PM +0200, David Seifert wrote:
> 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.
The *infra* packages here work fine, and pass their own tests.

> 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).
I explicitly said that hiera-eyaml & hiera-eyaml-gpg DO work with Ruby
3.2 even. It's only their test dependency, dev-util/aruba:0 that fails
it's own tests.

So you're implying that we are now responsible to fix the tests of every
package in our dependency tree, and you'll just remove all dependent
packages if we don't do that.

And if that's the case why didn't graaff mask dev-util/aruba:0 in
addition to hiera-eyaml & hiera-eyaml-gpg?

> 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.
I didn't say keep Ruby27 at all. hiera-eyaml in the tree WORKS on Ruby
3.0 & Ruby 3.1, and passes it's own testsuite.

The fix for Aruba:0 is just tweaking the cucumber tag syntax:
"~@foo" -> "not @foo"

I'll do the better fix anyway, making hiera-eyaml use aruba:2 instead, I
really just want better communication that we're now responsible for the
entire deptree's tests.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: Last rites: dev-ruby/hiera-eyaml and dev-ruby/hiera-eyaml-gpg [ In reply to ]
On Sun, 2023-03-26 at 22:37 +0000, Robin H. Johnson wrote:
> So you're implying that we are now responsible to fix the tests of
> every
> package in our dependency tree, and you'll just remove all dependent
> packages if we don't do that.

Yes, that's how being responsible works in volunteer projects. You need
it, you take care of it. Of everything-it, not just the top-most
product and dump all the dependencies on somebody else.

--
Best regards,
Micha? Górny
Re: Last rites: dev-ruby/hiera-eyaml and dev-ruby/hiera-eyaml-gpg [ In reply to ]
On Sun, 2023-03-26 at 21:39 +0000, Robin H. Johnson wrote:

To start with your last question since that is the most fundamental one
for me:

> 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).

Yes, if you want packages to maintained by the Ruby team then they must
have working tests, and consequently the dependencies, including test
dependencies, must also have them. The test suites are the only thing
that makes it feasible to maintain a large number of ruby packages
without actually using them.


> 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

Yes, it looks like any working "puppet" command is fine. I've updated
this to depend on either puppet-agent or puppet.


Kind regards,

Hans
Re: Last rites: dev-ruby/hiera-eyaml and dev-ruby/hiera-eyaml-gpg [ In reply to ]
On Sun, 2023-03-26 at 22:37 +0000, Robin H. Johnson wrote:
>
> So you're implying that we are now responsible to fix the tests of
> every
> package in our dependency tree, and you'll just remove all dependent
> packages if we don't do that.

My answer would be yes, especially for packages maintained by a project
team and in an interpreted language. We have no compiler or other
checks to fall back on other than tests.

Obviously a dedicated maintainer who is using a package could determine
if a package is compatible (at least for their use case) in other ways,
but in this case the only other maintainer is also a project team.

> And if that's the case why didn't graaff mask dev-util/aruba:0 in
> addition to hiera-eyaml & hiera-eyaml-gpg?

Simply because I did not get to that yet and leaf dependencies have to
go first.

> The fix for Aruba:0 is just tweaking the cucumber tag syntax:
> "~@foo" -> "not @foo"

This comment prompted me to have another look at aruba-0.6.2 because I
was sure there was more work involved when I looked at this in the
past, but you are right and it turns out that the dependency on rspec:2
was (no longer) correct.

I have now updated the aruba-0.6.2 ebuilds and consequently unmasked
hiera-eyaml again.

> I'll do the better fix anyway, making hiera-eyaml use aruba:2
> instead, I
> really just want better communication that we're now responsible for
> the
> entire deptree's tests.

Using aruba:2 would be helpful here but I already looked at that a bit
and the change was not trivial. It would still be the better fix.

Kind regards,

Hans