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

[helix-nine]

startos/externalStorage.ts:66 declares the File Browser dependency as versionRange: '^2.62.2:1'. File Browser has since marked itself end-of-life — its title is now File Browser (unsupported), it raises a permanently-failing end-of-life health check, and it tells users to switch to FileBrowser Quantum, which ships under the same id: 'filebrowser' with flavor #quantum.

A flavored version satisfies no unflavored range. Verified against the installed SDK:

VersionRange.parse('^2.62.2:1').satisfiedBy(ExtendedVersion.parse('#quantum:1.5.2:0'))  =>  false

So a user with External Storage → File Browser enabled who follows the EOL notice and switches flavors ends up with a filebrowser dependency Nextcloud can never satisfy. StartOS reports the dependency as unmet, and the only way to clear it is to turn External Storage off — while README.md:237, instructions.md:37 and startos/manifest/index.ts:41 all still present File Browser as the one supported source.

Not urgent: the Quantum flavor is not in either registry yet (production best for filebrowser is 2.63.23:0). But the range has to grow a flavored anchor — or the registry entry has to move to Quantum — before that switch becomes available to users, not after.

Found while reviewing #131.

[MattDHill]

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.

[helix-nine]

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.