External Storage's filebrowser versionRange cannot follow the dependency to its #quantum flavor #130

Activity

1. MattDHill commented on Aug 23, 2026

   

   MattDHill

   on Aug 23, 2026

   Member

   More actions

   Closing — this is already handled, by the mechanism that exists for exactly this case.

   The direct check in the report is right: a flavored version satisfies no unflavored range, and VersionRange.parse('^2.62.2:1').satisfiedBy(ExtendedVersion.parse('#quantum:1.5.2:0')) is false. But StartOS never asks only that question. It also checks the dependency's satisfies aliases:

   !this.exver.satisfies(depManifest.version, expected) &&
   !depManifest.satisfies.some(v => this.exver.satisfies(v, expected))

   — projects/start-os/web/ui/src/app/services/dep-error.service.ts:129-130

   And filebrowser-quantum-startos declares one for precisely this reason (startos/versions/current.ts:84, .satisfies('2.63.23:0')), which the beta registry serves today:

   #quantum:1.5.2:0 -> satisfies: ['2.63.23:0']
   

   ^2.62.2:1 is satisfied by 2.63.23:0, so a user who switches to the Quantum flavor keeps a satisfied filebrowser dependency. No change is needed on the Nextcloud side, and widening the range to a flavored anchor would duplicate the alias in a second place that has to be maintained.

   Two related facts worth recording, since both were checked while confirming this:

   • The integration is structurally compatible with Quantum: it has a data volume and chowns it 1000:1000 (startos/utils.ts, chownCommand), which is what main.ts's mountDependency + idmap: [{ fromId: 1000, toId: 33 }] needs.
   • Quantum is in the beta registry already, not absent from both as the report says. Production best for filebrowser is still 2.63.23:0.

   The thing to watch is Quantum's alias, not Nextcloud's range: if Quantum ever drops satisfies or moves it below 2.62.2:1, this breaks. That belongs on filebrowser-quantum-startos if it's worth tracking at all.
2. MattDHill

   closed this as completedon Aug 23, 2026
3. helix-a commented on Aug 23, 2026

   

   helix-a

   on Aug 23, 2026

   MemberAuthor

   More actions

   Confirmed, and the close is right. I re-checked the three load-bearing facts rather than take them from the report:

   • filebrowser-quantum-startos/startos/versions/current.ts:84 declares .satisfies('2.63.23:0') under version: '#quantum:1.5.2:0'.
   • The beta registry serves it that way — #quantum:1.5.2:0 with satisfies: ["2.63.23:0"], alongside unflavored 2.63.23:2 in best. Production best is still 2.63.23:0, as you said.
   • ExtendedVersion.parse('2.63.23:0').satisfies(VersionRange.parse('^2.62.2:1')) is true.

   So my report was wrong twice: it never considered the satisfies alias, and it claimed Quantum was in neither registry when it is in beta. Nothing to change here, and I agree the thing to watch is Quantum's alias rather than this range.

   One correction to a claim we both made, since it turns out to be false as stated. "A flavored version satisfies no unflavored range" holds for anchors, not for ranges generally — compare returns null across flavors, so every anchor comparison fails but negations succeed:

   #quantum:1.5.2:0  vs  ^2.62.2:1     ->  false
   #quantum:1.5.2:0  vs  >=2.0.0:0     ->  false
   #quantum:1.5.2:0  vs  !=2.63.23:0   ->  true
   #quantum:1.5.2:0  vs  *             ->  true
   

   That is a detail here, but it is the whole of a separate defect I hit while confirming this, so it is worth writing down.

   Adjacent SDK bug, not a Nextcloud one. Inside start-core's checkDependencies, the two forms of the same question disagree on exactly this case: satisfied() compared only installedVersion, while throwIfNotSatisfied() compared [installedVersion, ...satisfies]. So the boolean surface would report a #quantum File Browser — or a #knots Bitcoin — unsatisfied while the throwing surface passed and the UI showed it satisfied. Latent, not live: across 144 *-startos repos the only two checkDependencies call sites both use the throwing form. Fix in Start9Labs/start-technologies#3796.

   Reviewing that fix turned up something I deliberately did not fold into it — the alias union is existential, so a negated range is escapable:

   range '>=2.0:0 && !=2.0:5', installed 2.0:5, satisfies ['2.0:4']  ->  satisfied
   

   A dependent excluding a revision it knows is broken gets a green light through an ordinary compat alias. That semantics is shared with dep-error.service.ts and dry-update.ts, so narrowing it spans the OS, UI and SDK — filed as Start9Labs/start-technologies#3797 rather than decided in a patch.