Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Ideas to simplify the project going forward

Đang mở
  • Có gì không ổn?
#1,207 7 bình luận 8 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
linux
Lĩnh vực
devops, operating-systems

Hướng nghiên cứu

Bắt đầu bằng cách đọc draft.md của AppImageSpec và static runtime release được liên kết, sau đó đối chiếu runtime và các repository của AppImageKit với các mục 1–11 trong checklist. Công việc được xem là hoàn tất khi roadmap rộng này được thu hẹp thành một nhiệm vụ cụ thể đã thống nhất và hoàn thành đặc tả, tài liệu, việc di chuyển repository hoặc thay đổi runtime tương ứng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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"
Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
9.5k
Fork
586
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của AppImage/AppImageKit

Tất cả issue của AppImage/AppImageKit

Issue tương tự

Thêm issue về DevOps

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.