JMR-dev/LibreMediaConverter
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

Note that the catalog's room version does not control the Room that actually runs #130

New Issue
Open
opened 2026-08-26 05:25:50 +00:00 by JMR-dev · 1 comment
JMR-dev commented 2026-08-26 05:25:50 +00:00 (Migrated from github.com)
Copy Link
Copy Source

gradle/libs.versions.toml declares Room and never uses it:

room = "2.+"
androidx-room-runtime  = { group = "androidx.room", name = "room-runtime",  version.ref = "room" }
androidx-room-ktx      = { group = "androidx.room", name = "room-ktx",      version.ref = "room" }
androidx-room-compiler = { group = "androidx.room", name = "room-compiler", version.ref = "room" }

Measured on dc8b7c3:

  • grep -rn "libs\.androidx\.room" across every .kts/.gradle in the repo -> nothing.
  • No source file in main, test or androidTest imports androidx.room.
  • ksp is not applied to the module, so room-compiler could not run even if it were declared.

Room is on the classpath, but only transitively:

androidx.room:room-runtime:2.7.0
\--- androidx.work:work-runtime:2.11.2
     \--- androidx.work:work-runtime-ktx:2.11.2
          +--- debugRuntimeClasspath (requested androidx.work:work-runtime-ktx:2.+)

This is worse than clutter, because of #125. That ticket is a lock-order inversion inside Room's
coroutine executor. Anyone debugging it will reasonably try raising Room — and the obvious lever,
room = "2.+" in the catalog, does nothing at all. The version that matters is whatever
work-runtime brings (2.7.0 today), and changing it needs a resolution strategy, not a catalog edit.
A dead entry that looks exactly like the right knob is a trap, and it is sitting where someone is
about to step.

Suggested fix: delete the four lines. If Room is wanted directly later, adding it back is one
commit and would come with ksp and an actual usage.

Worth checking while in there rather than assuming: whether anything else in the catalog is
declared and unreferenced. The same grep pattern answers it per entry, and versions here float on
minor+patch, so an unused entry also quietly widens what a --refresh-dependencies run can change.

Not urgent, and deliberately not folded into #125 — that ticket is about the deadlock, and a
dependency-hygiene diff inside it would make the interesting part harder to review.

`gradle/libs.versions.toml` declares Room and never uses it: ```toml room = "2.+" androidx-room-runtime = { group = "androidx.room", name = "room-runtime", version.ref = "room" } androidx-room-ktx = { group = "androidx.room", name = "room-ktx", version.ref = "room" } androidx-room-compiler = { group = "androidx.room", name = "room-compiler", version.ref = "room" } ``` Measured on `dc8b7c3`: - `grep -rn "libs\.androidx\.room"` across every `.kts`/`.gradle` in the repo -> **nothing**. - No source file in `main`, `test` or `androidTest` imports `androidx.room`. - **`ksp` is not applied to the module**, so `room-compiler` could not run even if it were declared. Room *is* on the classpath, but only transitively: ``` androidx.room:room-runtime:2.7.0 \--- androidx.work:work-runtime:2.11.2 \--- androidx.work:work-runtime-ktx:2.11.2 +--- debugRuntimeClasspath (requested androidx.work:work-runtime-ktx:2.+) ``` **This is worse than clutter, because of #125.** That ticket is a lock-order inversion inside Room's coroutine executor. Anyone debugging it will reasonably try raising Room — and the obvious lever, `room = "2.+"` in the catalog, **does nothing at all**. The version that matters is whatever `work-runtime` brings (2.7.0 today), and changing it needs a resolution strategy, not a catalog edit. A dead entry that looks exactly like the right knob is a trap, and it is sitting where someone is about to step. **Suggested fix:** delete the four lines. If Room is wanted directly later, adding it back is one commit and would come with `ksp` and an actual usage. **Worth checking while in there** rather than assuming: whether anything else in the catalog is declared and unreferenced. The same grep pattern answers it per entry, and versions here float on minor+patch, so an unused entry also quietly widens what a `--refresh-dependencies` run can change. Not urgent, and deliberately not folded into #125 — that ticket is about the deadlock, and a dependency-hygiene diff inside it would make the interesting part harder to review.
JMR-dev commented 2026-08-26 05:54:30 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Correcting this ticket: the entries are deliberate, and deleting them would destroy recorded intent

I filed this recommending "delete the four lines". Do not do that. I missed the comment sitting
directly above them in gradle/libs.versions.toml:

# Room — job history. Added in a later phase; KSP plugin stays unapplied until then.
androidx-room-runtime  = { group = "androidx.room", name = "room-runtime",  version.ref = "room" }
androidx-room-ktx      = { group = "androidx.room", name = "room-ktx",      version.ref = "room" }
androidx-room-compiler = { group = "androidx.room", name = "room-compiler", version.ref = "room" }

They are staged for a planned feature, and the comment even pre-answers the objection I raised —
ksp is unapplied on purpose, until job history lands. That is forward declaration with its
reasoning written down, which is this file's established habit, not clutter.

How I missed it: I searched with grep -n "room", which is case-sensitive, so # Room — job history never matched. Every check I ran after that — no libs.androidx.room reference, no import,
no ksp — was true and pointed the wrong way, because the one line that explained why was
invisible to my filter. Two greps agreeing is not corroboration when they share a blind spot.

What actually survives, and it is narrower

The real finding is about #125, not about the catalog being untidy:

Room's runtime version is not controlled by room = "2.+". Nothing applies those entries, so
Room reaches the classpath only via androidx.work:work-runtime:2.11.2, which brings 2.7.0.
Raising room = "2.+" changes nothing until job history ships.

That trap is real and someone debugging #125's Room deadlock will walk into it. But the fix is one
line of comment, not four deletions:

# Room — job history. Added in a later phase; KSP plugin stays unapplied until then.
# Until then nothing applies these: Room is on the classpath only transitively, via
# work-runtime (2.7.0 today), so changing `room` here does not move the version that runs.

Retitling

The current title — "the catalog declares Room and nothing uses it" — states the symptom as though it
were the defect. It is neither surprising nor wrong. Suggest: "Note that room in the catalog does
not control the Room that actually runs".

Dropping the severity would be fair too. This is a comment improvement that saves someone an hour on
#125, not a hygiene problem.

## Correcting this ticket: the entries are deliberate, and deleting them would destroy recorded intent I filed this recommending "delete the four lines". **Do not do that.** I missed the comment sitting directly above them in `gradle/libs.versions.toml`: ```toml # Room — job history. Added in a later phase; KSP plugin stays unapplied until then. androidx-room-runtime = { group = "androidx.room", name = "room-runtime", version.ref = "room" } androidx-room-ktx = { group = "androidx.room", name = "room-ktx", version.ref = "room" } androidx-room-compiler = { group = "androidx.room", name = "room-compiler", version.ref = "room" } ``` They are **staged for a planned feature**, and the comment even pre-answers the objection I raised — `ksp` is unapplied *on purpose*, until job history lands. That is forward declaration with its reasoning written down, which is this file's established habit, not clutter. **How I missed it:** I searched with `grep -n "room"`, which is case-sensitive, so `# Room — job history` never matched. Every check I ran after that — no `libs.androidx.room` reference, no import, no `ksp` — was true and pointed the wrong way, because the one line that explained *why* was invisible to my filter. Two greps agreeing is not corroboration when they share a blind spot. ## What actually survives, and it is narrower The real finding is about **#125**, not about the catalog being untidy: > Room's runtime version is **not** controlled by `room = "2.+"`. Nothing applies those entries, so > Room reaches the classpath only via `androidx.work:work-runtime:2.11.2`, which brings **2.7.0**. > Raising `room = "2.+"` changes nothing until job history ships. That trap is real and someone debugging #125's Room deadlock will walk into it. But the fix is **one line of comment**, not four deletions: ```toml # Room — job history. Added in a later phase; KSP plugin stays unapplied until then. # Until then nothing applies these: Room is on the classpath only transitively, via # work-runtime (2.7.0 today), so changing `room` here does not move the version that runs. ``` ## Retitling The current title — "the catalog declares Room and nothing uses it" — states the symptom as though it were the defect. It is neither surprising nor wrong. Suggest: *"Note that `room` in the catalog does not control the Room that actually runs"*. Dropping the severity would be fair too. This is a comment improvement that saves someone an hour on #125, not a hygiene problem.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
above-cut
Worked autonomously overnight: local, JVM-verifiable, no product decision
 accessibility
Barrier affecting people with disabilities
 backlog
Held for manual review: product/UX call, CI/workflow, hardware, or unverifiable here
 bug
Something isn't working
 confirmed
Reviewer demonstrated the defect
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 plausible
Reviewer could not fully demonstrate it; treat as unproven
 question
Further information is requested
 sev:high
High severity
 sev:low
Low severity
 sev:medium
Medium severity
 wontfix
This will not be worked on
No labels confirmed sev:low
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
JMR-dev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#130