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

Define a way for websites to link to AppImage downloads

Aperta
  • Qualcosa non va?
#1,074 10 commenti 0 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
release

Direzione di ricerca

Inizia esaminando la documentazione di AppStream relativa a custom-tag e le indicazioni esistenti di KDE su custom-tag, quindi confronta questi requisiti con la stringa delle informazioni di aggiornamento di AppImage descritta nell’issue. Decidi se il progetto debba esporre link consapevoli del canale tramite AppStream o riutilizzare i metadati di aggiornamento, e documenta se il risultato è un download diretto o una landing page senza versioni hardcoded.

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

Descrizione

Use case:
https://kde.org/applications/ shows download links for the Windows, Android... app store.
How should AppImages be represented there, and where should the information come from?

The AppStream spec allows specifying URLs to e..g, the application homepage, bugtracker, etc. - but not to, e.g., "the latest AppImage for the stable channel".

Turns out that the AppStream spec allows for custom tags:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-custom

KDE is already making use of custom tags:
https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags
cc
So the question is, do we need/want custom tags for AppImage downloads.

Requirements:

  • The information in the AppStream metainfo file must not hardcode version numbers
  • The information in the AppStream metainfo file should allow for multiple channels (e.g., release, nightly, alpha, beta,..)

Question:

  • Do we want a "deeplink" that results in the AppImage being downloaded, or do we want a link to the download page on which the AppImage can be downloaded by the user?

Food for thought:

  • Do we even need AppStream for this purpose? We could re-use AppImage update information for this purpose. This might completely remove the need for using AppStream to get this kind of information, it is already there and it already supports different channels

@jriddell: AppImage update information is a text string that is embedded within the first few KB of AppImages that support automatic updating (hopefully all of the KDE ones do!). From this string, the URL to the AppImage download can be constructed. Would that be an approach that would be acceptable for this use case, or do you think the information must come from AppStream?

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 Release

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.