User Story:
One of the benefits of existing packaging formats like .eopkg, .rpm, and .deb is that they are easily accessible using tools already installed on packagers machines. It is for example possible to build a package in Solus and then double click on the built .eopkg in Plasma/GNOME/Whatever to open it up in the default archive handler for that DE (Ark on Plasma for example). The actual files inside the package are fully visible and can be extracted and examined individually for whatever reason the packager has in mind.
The packager can even use something like diffoscope between builds of the package to determine exact binary differences between the two packages, which helps in debugging issues with both the package and tooling as well as determining reproducibility issues with the build itself.
Both of these use-cases should be possible using the .stone package format as well.
How:
The lowest-effort-to-greatest-results option is likely to add to libarchive the ability to parse the .stone binary format. To do this we will likely need to create a "libstone" (working name), a shared library that we can create different language bindings against (including C for libarchive). This library should understand the .stone binary format and should be able to translate it into filesystem metadata as well as allow files to be individually extracted from the format. This shared library should have a stable ABI and use semantic versioning for ABI breaks. Likely, we will want to release the shared library code independently so that distros that have no desire to build moss/boulder can build just libstone (if libstone is developed in this repo it probably makes sense to have a .tar generation process for it that strips out all of the code it doesn't need from libstone-version.tar.zst for example).
Non-goals:
- It is probably not necessary to allow libstone to create .stone files
Some cursory articles I could find on the subject:
User Story:
One of the benefits of existing packaging formats like .eopkg, .rpm, and .deb is that they are easily accessible using tools already installed on packagers machines. It is for example possible to build a package in Solus and then double click on the built .eopkg in Plasma/GNOME/Whatever to open it up in the default archive handler for that DE (Ark on Plasma for example). The actual files inside the package are fully visible and can be extracted and examined individually for whatever reason the packager has in mind.
The packager can even use something like diffoscope between builds of the package to determine exact binary differences between the two packages, which helps in debugging issues with both the package and tooling as well as determining reproducibility issues with the build itself.
Both of these use-cases should be possible using the .stone package format as well.
How:
The lowest-effort-to-greatest-results option is likely to add to libarchive the ability to parse the .stone binary format. To do this we will likely need to create a "libstone" (working name), a shared library that we can create different language bindings against (including C for libarchive). This library should understand the .stone binary format and should be able to translate it into filesystem metadata as well as allow files to be individually extracted from the format. This shared library should have a stable ABI and use semantic versioning for ABI breaks. Likely, we will want to release the shared library code independently so that distros that have no desire to build moss/boulder can build just libstone (if libstone is developed in this repo it probably makes sense to have a .tar generation process for it that strips out all of the code it doesn't need from libstone-version.tar.zst for example).
Non-goals:
Some cursory articles I could find on the subject: