[MIR] Promote ruby-ruby2-keywords to main as a pcs indirect dependency

[Lucas Kanashiro]

[Availability]

The package ruby-ruby2-keywords is already in Ubuntu universe.

The package ruby-ruby2-keywords build for the architectures it is designed to work on.

It currently builds and works for architectures: amd64 (arch:all)

Link to package [[https://launchpad.net/ubuntu/+source/ruby-ruby2-keywords|ruby-ruby2-keywords]]

[Rationale]

The package ruby-ruby2-keywords is required in Ubuntu main for ruby-mustermann promotion which is needed by ruby-sinatra, and ruby-sinatra is a runtime dependency of pcs (the main reason for this promotion).

Ideally, we expect that ruby-ruby2-keywords (and pcs) will be promoted in the "L" development cycle. The idea is to promote only the ruby-ruby2-keywords binary.

[Security]

Required links:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ruby2-keywords

Nothing was found searching for the gem name.

Nothing was found searching in the OSS security mailing list archive.

https://ubuntu.com/security/cves?package=ruby-ruby2-keywords

Also nothing found in the Ubuntu security tracker.

No CVEs/security issues in this software in the past.

No `suid` or `sgid` binaries.

Package does not install services, timers or recurring jobs.

Packages does not open privileged ports (ports < 1024).

Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...).

[Quality assurance - function/usage]

The package works well right after install.

[Quality assurance - maintenance]

The package is maintained well in Debian/Ubuntu and has no bugs open:

- Ubuntu https://bugs.launchpad.net/ubuntu/+source/ruby-ruby2-keywords/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ruby-ruby2-keywords

The package does not deal with exotic hardware we cannot support.

[Quality assurance - testing]

The package runs a test suite on build time, if it fails
it makes the build fail, link to build log:

https://launchpadlibrarian.net/571658904/buildlog_ubuntu-jammy-amd64.ruby-ruby2-keywords_0.0.5-1_BUILDING.txt.gz

The package runs an autopkgtest, and is currently passing on
this list of architectures: amd64, arm64, armhf, ppc64el, s390x.

Link to test logs:

https://autopkgtest.ubuntu.com/packages/ruby-ruby2-keywords

The package does not have failing autopkgtests right now. Only in i386, where some dependencies are not installable.

[Quality assurance - packaging]

debian/watch is present and works.

debian/control defines a correct Maintainer field.

Nothing is reported by `lintian --pedantic`.
Lintian overrides are not present.

This package does not rely on obsolete or about to be demoted packages.

The package will not be installed by default.

Packaging and build is easy, link to d/rules:

https://git.launchpad.net/~git-ubuntu-import/ubuntu/+source/ruby-ruby2-keywords/tree/debian/rules

[UI standards]

Application is not end-user facing (does not need translation).

[Dependencies]

No further depends or recommends dependencies that are not yet in main.

[Standards compliance]

This package correctly follows FHS and Debian Policy.

[Maintenance/Owner]

Owning Team will be Server.

Team is not yet, but will subscribe to the package before promotion.

This does not use static builds.

This does not use vendored code.

This package is not rust based.

The package has been built in the archive more recently than the last
test rebuild.

[Background information]

The Package description explains the package well.

Upstream Name is: ruby2_keywords

Link to upstream project: https://github.com/ruby/ruby2_keywords

[Christian Ehrhardt  (paelzer)]

Review for Package: ruby-ruby2-keywords

[Summary]
MIR team NACK - at least until it is clear why we need this dependency.

Required TODOs:
- Please explain why a package defined as "source-level compatibility
  library between ruby2.7 and ruby3 ... On ruby3, it does nothing."
  is needed to promote a package in a ruby3 environment (lunar)?
  I've ran `dpkg --remove --force-depends ruby-ruby2-keywords` and it seemed
  to work fine still in a ruby = ruby3 environment.
  I think this might be an artifact of past transitions or over-compatibility
  and we could get rid of it.
  You are more of a ruby expert, could you give it a closer look please?

Just like with ruby-backports I'm stopping the evaluation here, happy to
re-start it once a case has been made why we really would need it.

[Lucas Kanashiro (lucaskanashiro)]

Thanks for this initial review Christian.

ruby-ruby2-keywords is a dependency of ruby-mustermann. I took a look at ruby-mustermann if we could easily patch it out, turns out that it is not that easy. To transition the library to ruby 3, the way upstream fixed the positional and keyword argument breaking change [1] was using the ruby2_keywords gem, this is listed by ruby interpreter upstream as one way to fix the issue without the need to write code to comply with ruby 3 changes, keeping the old code. I tried to simple remove the ruby2_keywords calls but then 3/4 of the test suite failed and it is not so straightforward to fix them throughout the code base. Upstream also supports ruby >= 2.6, so they are not willing to move away from that implementation right now.

The ruby-ruby2-keywords gem is pretty small and quite low maintenance, could we consider keeping it as a dependency of ruby-mustermann and promote it to main?

[1] https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/

[Christian Ehrhardt  (paelzer)]

Review for Package: ruby-ruby2-keywords

Thanks for the answer Lucas, I agree to your analysis.
And it was worth having a look, at least we got rid of ruby-backports with
the same approach.

I agree that the lib itself is small and not too complex, so I'm doing a
re-revaluation. Along that - as expected - it is IMHO a rather straight
forward case.

[Summary]
MIR team ACK

This does not need a security review.

List of specific binary packages to be promoted to main: ruby-ruby2-keywords
Specific binary packages built, but NOT to be promoted to main: <none>

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning (none)
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
  It really is just a syntax compatibility layer, not even parsing or
  translating the data on the way through.
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems: None

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  Doesn't test much, but then the function is also rather small, tests
  it in both ruby language styles which is importnat given what this
  PKG does.
  - test suite fails will fail the build upon error.
- does have a non-trivial test suite that runs as autopkgtest
  (same as build tests, which is ok for this code)
- This does not need special HW for build or test
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is slow, but ok
- Debian/Ubuntu update history is slow (ok, following upstreams slowness)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package (most maint is with debian ruby team which we
  have team members being a part of)
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no u...

[Christian Ehrhardt  (paelzer)]

Promoted together with the full PCS stack, details see https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1953341/comments/13