get_manually_installed_packages() requires a /var/log/installer/initial-status.gz

Abierto
#76 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend, desktop

Línea de trabajo

Empieza en usr/lib/python3/dist-packages/mintcommon/installer/cache.py, en PkgCache.get_manually_installed_packages() y _get_manually_installed_debs(), y reproduce el problema cuando /var/log/installer/initial-status.gz no está presente. Comprueba la vista de paquetes instalados en mintinstall y el comportamiento público documentado; se considera terminado cuando la ausencia del archivo del instalador ya no deja vacía la lista de paquetes y el contrato del método es correcto.

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

Descripción

On systems not having the file "/var/log/installer/initial-status.gz", mintcommon.installer.cache.PkgCache.get_manually_installed_packages() will just return None, not even trying to return a flatpak list and not trying alternative direct apt or dpkg queries for listing installed packages.

Based on an Askbuntu answer and reading the code, the purpose of the file initial-status.gz seems to have been to record which packages came from the system installer, as opposed to those added later by the user. But some installers have apparently stopped providing initial-status.gz. I used mintupgrade 2025.11.21 and noticed that I don't have this file now. (As I previously used synaptic rather than mintinstall, I didn't notice any problem until now and I don't know whether I had the file before the upgrade either.) If the distinction between package installaction cause can not be made, it would seem better to list all installed packages (regardless of cause) than to list none as installed. Mintinstall and Mintbackup seem to fail to list installed packages due to this behaviour.

To confirm that the missing file was the only problem, I created a plain text file /tmp/initial-status with a single line saying

Package: mintinstall

(It doesn't seem to matter which package name is used, just a space might work too.)
I then ran gzip /tmp/initial-status and sudo mv -n /tmp/initial-status.gz /var/log/installer/initial-status.gz to put this gzipped file where mintcommon expects to find a file with at least one line starting with "Package: ".

Now, running mintinstall and going to the "Show installed applications" gives me a long list, including both system packages and flatpak packages. (Before this list was empty, except the specific installed packages whose details I had open in mintinstall.). Actually, I can then remove the .gz-file, and mintinstall keeps showing a list of installed packages (probably cached somewhere, but clicking to reload the list of packages didn't clear it.)

  • Is it a formal requirement that all Linux Mint (Debian Edition) installers create /var/log/installer/initial-status.gz? So the bug would be in whichever didn't?
  • Should mintcommon's get_manually_installed_packages() work even when the file is missing? I would prefer the latter, just listing all packages if there's no other method to exclude some that came from a system-installer.

The docstring of the problematic private method _get_manually_installed_debs() does document that it "Requires a package list provided by the installer. Currently knows only Ubiquity's /var/log/installer/initial-status.gz". However, this caveat is not mentioned on the public method get_manually_installed_packages(), which just says "Get list of all manually installed packages (apt and flatpak)". And I guess the mintinstall and mintbackup packages were not realizing this limitation and did not happen to test on a system without this file.

Lenguaje dominante
Python
Estrellas
25
Forks
32
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

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 linuxmint/mintcommon

Todos los issues de linuxmint/mintcommon

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.