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

Ideas to simplify the project going forward

Abierto
  • ¿Algo no está bien?
#1,207 7 comentarios 8 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
linux
Área
devops, operating-systems

Línea de trabajo

Comienza leyendo draft.md de AppImageSpec y la static runtime release enlazada; después, compara el runtime y los repositorios de AppImageKit con los elementos de la checklist 1–11. Se consideraría terminado cuando esta hoja de ruta amplia se haya concretado en una tarea específica y acordada, y se haya completado la especificación, documentación, traslado del repositorio o cambio del runtime correspondiente.

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

Descripción

idea

The AppImage format has spawned a large open source community ecosystem by now. At the same time, the AppImage project has become complex and unlike the original vision (probonopd/AppImageKit) where everything was meant to be small, simple, and in one repository has created a significant burden for the people maintaining it, including @TheAssassin and me.

So, going forward, I would like to:

  • Strengthen the community around the AppImage format, and delegate more of the actual code to that community, instead of trying to do everything inside the AppImage project
  • Reduce amount of code maintained inside the AppImage project to a bare minimum
  • Reduce complexity of code and repositories inside the AppImage project, and specifically inside the AppImageKit repository, to a bare minimum
  • Move everything else to community project(s) outside of https://github.com/AppImage/

My personal itches:

  • Remove "complicated" (for me!) dependencies (like C++, CMake, and libappimage) for what remains inside the AppImage project, and specifically inside the AppImageKit repository, and have those things maintained by the community
  • Switch to a static AppImage runtime that is more robust against future changes in Linux distributions (like this one)
  • For the essential AppImage tools, deliver them as AppImages that bundle everything or as static binaries, to make them more robust against future changes in Linux distributions
  • Reduce the amout of stuff that I have to feel somehow respronsible for to essentially the AppImage spec and a very small set of tools
  • Have to care roughly only about https://github.com/AppImage/AppImageSpec/, https://github.com/probonopd/static-tools/, possibly parts of https://github.com/probonopd/go-appimage/ in the AppImage project
  • Ideally standardize on Golang where possible, statically link where not possible
  • Prevent developers from producing AppImages/AppImages that don't "just work" on all still-supported Linux distributions and ideally even FreeBSD which I am pretty much exclusively using these days (e.g., by promoting AppImages that bundle everything)

Result of brainstorming with @TheAssassin earlier this year:

  • 1. Version AppImageSpec; in a new version reduce/remove room for ambiguity
  • 2. Write an AppDir spec. So far we just pointed at http://rox.sourceforge.net/desktop/AppDirs.html but factually started to use non-mandatory conventions like a top-level desktop file used by some of our AppRun implementations. It needs to be clarified whether things like that are MUST/SHOULD/CAN
  • 3. In a new AppImage type, use a "resource system" that allows us to put e.g., update information and similar metadata into AppImages (and possibly other ELF compliant files) in a standardized way that is easy to parse e.g., by file managers (similar to what Haiku does but using a simpler format like .ar?)
  • 4. Document how to create AppDirs/AppImages that bundle everything and that decide at runtime which version of things like GPU related libraries to use; document the tradeoffs between AppDirs/AppImages that bundle everything and "traditional" AppDirs/AppImages
  • 5. Move non-essential repositories out of the AppImage project
  • 6. Move everything except the runtime out of the AppImageKit repository
  • 7. Replace runtime by static runtime
  • 8. Print a message if the AppImage was built on a newer system than the target system on which the AppImage is running (can be approximated e.g., by looking at glibc versions or something like that)
  • 9. Document and support TARGET_APPIMAGE Done
  • 10. Document system requirements and assumptions, e.g., regarding fusermount

Update 11/2024:

  • 11. Promote "AppImages that bundle everything"
Lenguaje dominante
Sin datos de lenguaje
Estrellas
9.5k
Forks
586
Sin PR fusionados en 30 d

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 AppImage/AppImageKit

Todos los issues de AppImage/AppImageKit

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.