Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,011 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
65/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
electron, linux
Área
desktop, documentation

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
16.3k
Forks
1.6k
Merge medio
12 h 13 min
PR fusionados (30 d)
274

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MODSetter/SurfSense

Todos los issues de MODSetter/SurfSense

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.