Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Ideas to simplify the project going forward

オープン
  • 何か問題がありますか？
#1,207 コメント 7 件 リアクション 8 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
linux
領域
devops, operating-systems

調査の方向性

まず AppImageSpec の draft.md とリンクされた static runtime release を読み、次に AppImageKit の runtime とリポジトリを checklist の項目 1–11 と比較します。完了とみなすには、この広範なロードマップを具体的で合意済みのタスクに絞り込み、対応する仕様、ドキュメント、リポジトリの移動、または runtime の変更を完了する必要があります。

索引モデルが issue の本文から書いたものです。

説明

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"
主要言語
言語のデータがありません
スター
9.5k
フォーク
586
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

AppImage/AppImageKit のほかの issue

AppImage/AppImageKit の issue をすべて見る

似ている issue

DevOps の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。