Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Ideas to simplify the project going forward

Aperta
  • Qualcosa non va?
#1,207 7 commenti 8 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
linux
Ambito
devops, operating-systems

Direzione di ricerca

Inizia leggendo draft.md di AppImageSpec e la static runtime release collegata, quindi confronta il runtime e i repository di AppImageKit con gli elementi della checklist 1–11. Il lavoro sarebbe considerato completato quando questa roadmap generica fosse circoscritta a un'attività specifica e concordata e fossero completati la relativa specifica, documentazione, lo spostamento del repository o la modifica del runtime.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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"
Lingua principale
Nessun dato sulla lingua
Stelle
9.5k
Fork
586
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di AppImage/AppImageKit

Tutte le issue di AppImage/AppImageKit

Issue simili

Altre issue su DevOps

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.