Skip to content

fix: allow installing updates from local deb files - #2217

Merged
ogres merged 3 commits into
ubuntu:mainfrom
skdas20:fix/local-deb-version-detection
Oct 23, 2026
Merged

ogres merged 3 commits into
ubuntu:mainfrom
skdas20:fix/local-deb-version-detection

Conversation

@skdas20

@skdas20 skdas20 commented Oct 3, 2026

Copy link
Copy Markdown
Contributor

Opening a local .deb currently disables installation whenever a package with the same name is installed, even when the installed version differs from the file. For example, an installed 0.9 package makes a local 1.0 package appear already installed.

Require the installed package version to match the local file version before reporting isInstalled. A differing version keeps the existing installation and confirmation flow available. PackageKit remains responsible for validating the requested installation; this does not attempt to sort Debian version strings.

Fixes #2190.

Validation with the pinned Flutter 3.44.9 SDK:

  • Added a widget regression that starts with installed 0.9, opens local 1.0, confirms the enabled Install action and verifies installLocal receives the file path.
  • This regression fails against unchanged main at the disabled Installed button and passes with the fix.
  • Existing coverage still verifies that the same installed version disables the button.
  • Full melos test: 371 app tests and 6 ratings-client tests passed.
  • melos analyze --fatal-infos, melos format:exclude and git diff --check passed.

AI-assisted implementation and test execution.

@ogres

ogres commented Oct 3, 2026

Copy link
Copy Markdown
Collaborator

@skdas20 Could you please share a screenshot how it looks with the changed logic?
Since we now check only direct comparison for versions - it will now allow older versions too, not just update, any reason for that?

@skdas20

skdas20 commented Oct 3, 2026

Copy link
Copy Markdown
Contributor Author

@ogres Thanks for checking. These are headless Flutter renders of the actual LocalDebPage using the Yaru theme and mocked PackageKit data, rather than a full desktop run. The local file is testdeb version 1.0 in every case.

Installed 0.9, local 1.0:

Before With the patch
Before: Installed action disabled for local 1.0 with installed 0.9 After: Install action enabled for local 1.0 with installed 0.9

You're right about older files. I used equality to answer whether the exact version in the local file is already installed. That unblocks the update case, but also enables a different older version, so the current change is broader than an upgrade-only fix. The existing installation and confirmation flow remains in place, but I haven't added a separate downgrade policy.

If the intended behavior is to allow only upgrades, I can narrow the change using Debian version ordering and add a regression for the older-file case; a plain string comparison would not be sufficient.

Same-version, older-file and confirmation screenshots

Installed 1.0, local 1.0: Installed remains disabled.

Same version remains disabled

Installed 1.1, local 1.0: Install is also enabled with the current patch.

Older local file is also enabled

The existing confirmation dialog after clicking Install:

Existing installation confirmation

The screenshot fixture and the existing local-deb page tests pass (8 tests). Installed versions above are fixture inputs; the version displayed on the page is the local file's version. Capture details and harness.

@ogres

ogres commented Oct 3, 2026 •

Copy link
Copy Markdown
Collaborator

@skdas20 I think we need to give some kind of information to user that this package is already installed with version XYZ, so that they can understand it - otherwise, there is no way to know whether you have already installed a given package.

@skdas20

skdas20 commented Oct 4, 2026

Copy link
Copy Markdown
Contributor Author

Added Installed version: XYZ beside the action button whenever PackageKit reports an installed package. The label is shown for the same version and for both newer and older local files; available-only packages are not labelled as installed.

Updated screenshots (headless Flutter widget renders using mocked PackageKit metadata):

Local 1.0, installed 0.9:

Local 1.0, installed 0.9

Local 1.0, installed 1.0:

Local 1.0, installed 1.0

Local 1.0, installed 1.1:

Local 1.0, installed 1.1

The full test suite, analysis, and formatting checks pass. Regression tests cover updates, downgrades, the identical version, and available-only metadata.

@ogres
ogres requested a balanced review from Copilot October 5, 2026 19:45

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟡 Changes recommended

The package lookup can return an available entry instead of the installed package, producing an incorrect installation state.

Review effort: Balanced
Findings: 1 Medium severity

Open (1)
What changed in this PR

Enables installing a local Debian package when its version differs from the installed version.

Changes:

  • Compares installed and local package versions.
  • Displays the installed version.
  • Adds widget regression coverage for upgrades, downgrades, and available packages.
File Description
local_deb_model.dart Derives installed version and installation state.
local_deb_page.dart Displays the installed version.
app_en.arb Adds the localized version label.
local_deb_page_test.dart Tests local package installation behavior.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@ogres

ogres commented Oct 8, 2026

Copy link
Copy Markdown
Collaborator

@skdas20 Changes look good, but let's resolve the possible timing issue as reported above. Thanks!

@ogres

ogres commented Oct 19, 2026

Copy link
Copy Markdown
Collaborator

Hi @skdas20 , do you need help with this PR?

@skdas20

skdas20 commented Oct 21, 2026

Copy link
Copy Markdown
Contributor Author

Hi @ogres, thanks for checking in, and sorry for the delay. I'll fix the timing issue by resolving the package with installedOnly: true, so a late "available" event can't overwrite the installed entry, and add a regression test where the available event arrives after the installed one. I'll push it in the next couple of days.

@ogres

ogres commented Oct 22, 2026

Copy link
Copy Markdown
Collaborator

@skdas20 Nothing to be sorry about, thanks for the contribution. Ping me if you need any help

@skdas20

skdas20 commented Oct 22, 2026

Copy link
Copy Markdown
Contributor Author

Thanks — I pushed the follow-up in f4bf1bf. The local-deb lookup now resolves only installed packages, so a later available result cannot replace the installed version. I added a service-level regression test that emits an installed result followed by a newer available result, and a page-level assertion that the lookup requests installed results only.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The focused changes preserve installation safeguards and cover the relevant version and package-state cases, with no unresolved findings.

No open issues 🎉

1 resolved since last review

Review effort: Balanced

@ogres
ogres merged commit deee1be into ubuntu:main Oct 23, 2026
12 checks passed
@Whiletru3

Copy link
Copy Markdown

Nice, you already have an ETA for a deployment in 26.04 ? Thanks 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Local deb update issue

4 participants