Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Confirm whether an installed `.deb` auto-updates, and document the answer

Đang mở
  • Có gì không ổn?
#2,011 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
65/100
Loại issue
Tài liệu
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
electron, linux
Lĩnh vực
desktop, documentation

Hướng nghiên cứu

Read docs/architecture/updates.md, ADR 0020, and surfsense_local/electron/src/main/updater.ts; inspect resources/package-type in an installed v2.0.2 .deb. On an x64 Linux desktop, allow updates in Settings › About, record whether 2.0.3 is offered, downloads, and installs on restart, and attach the session log with your distribution and version. Replace the table's likelihood and remove the Known gaps line; if a code or configuration change proves necessary, use updater.test.ts and run pnpm test.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

desktop documentation help wanted

The gap

docs/architecture/updates.md lists this under Known gaps:

The deb build likely auto-updates, although the launch plan said it would not: electron-builder writes resources/package-type for a deb, electron-updater picks its deb updater from that file, and v2.0.2's stable-linux.yml on the release lists SurfSense.deb. Not checked on an installed deb.

Why it matters

The doc's release table currently says "likely the deb", and the launch plan said the deb would not update itself. Both cannot be true, and it is deb users who find out which. If it does update, someone who installed through their package manager gets an application that replaces itself outside it, and that deserves to be stated plainly rather than discovered. If it does not, stable-linux.yml advertises an asset no client can use and every deb user is quietly stuck on the version they installed, with the update row in Settings telling them nothing useful.

This is checkable now without cutting anything: v2.0.2 and v2.0.3 are both published, so an installed 2.0.2 deb has a newer release to find.

Where

What done looks like

  • A report on an x64 Linux desktop: install the published v2.0.2 .deb, allow updates in Settings › About, and say what happened — whether 2.0.3 was offered, whether it downloaded, and whether the restart action installed it.
  • resources/package-type inside the installed app is named as present or absent, with its contents. That file is the whole mechanism, so it is the first thing to look at and the cheapest half of the answer.
  • The doc's table cell states the answer rather than a likelihood, and the Known gaps line is gone.
  • Your environment is in the issue: distribution and version, and whether this was a real desktop session or a container. The answer may not be the same everywhere, and the next reader needs to know what was tested.
  • If it does update in a way that leaves the package manager's database stale, say so in the doc. Whether that needs fixing is a separate issue, not this one.

What not to change

Do not change publish.channel or allowPrerelease to make testing easier. The channel names are the only thing keeping 2.x manifests away from the legacy 0.0.x clients, and updater.ts records that dropping allowPrerelease changes behaviour for shipped clients and has to ship on its own.

How to verify

This one is answered by observation, so the report is the deliverable — attach the app's own session log from the update attempt. There is no existing test for it, and the honest thing is not to invent one against a released binary. If the answer turns out to need a code or configuration change, that change is TDD like any other: write its failing test first, in surfsense_local/electron/src/main/updater.test.ts, which already drives the updater.

python scripts/check_docs.py          # from the repo root, for the doc edit
cd surfsense_local/electron && pnpm test

Before you start

Read CONTRIBUTING.md, the updates doc and ADR 0020. Open your PR against dev, not main. Comment here to claim this, and say which distribution you can test on.

Ngôn ngữ chính
Python
Star
16.3k
Fork
1.6k
Merge trung bình
11 giờ 37 phút
Pull request đã merge (30 ngày)
261

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MODSetter/SurfSense

Tất cả issue của MODSetter/SurfSense

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.