Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Ideas to simplify the project going forward

未关闭
  • 哪里不对？
#1,207 7 条评论 8 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
20/100
Issue 类型
重构
描述清晰度
需要澄清
活跃度
停滞
技术栈
linux
领域
devops, operating-systems

调研方向

先阅读 AppImageSpec 的 draft.md 和链接的 static runtime release，然后将 AppImageKit 的 runtime 和 repositories 与 checklist 项目 1–11 进行对比。完成这项工作需要将这一宽泛的路线图缩小为一个具体且已达成共识的任务，并完成相应的规范、文档、repository 迁移或 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. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

AppImage/AppImageKit 的其他 Issue

查看 AppImage/AppImageKit 的全部 Issue

相似的 Issue

更多 DevOps Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。