cjdcordeiro
commented
4 hours ago Hi @NWarila
Thanks for reaching out and for your interest in this project :)
I've completed about 20 out of the 50 slice files needed
That's amazing. We'd be happy to review them!
1. OS Version-Specific Slice Databases
Observation 1:
The slice database is currently specific to each OS version (e.g., 24.04, 24.10), even though many slices are compatible across different versions. This setup appears to rely on slice maintainers manually porting each slice between OS versions, which is time-consuming and inefficient.
Suggestion 1:
By adding an application versioning property to the YAML slice files, we could unify the slice database and enable slices to work across multiple OS and package versions. This change would reduce duplication and simplify maintenance, facilitating broader compatibility without the need for manual porting.
You don't need to manually port your slices. Very much like the opening of a new Ubuntu release, everytime a new chisel-release opens, we merely copy the previous release's slice definitions files.
You may be referring to the fact that we encourage contributors to forward port new slice definitions. If that's the case, yes, indeed that is true. It is a necessary effort in order to guarantee a smaller gap between releases. Forward porting will slowly become redundant once we match the number of packages that exist in the Ubuntu archives.
You are right to say that certain slice definitions do indeed remain unchanged between Ubuntu releases. However, grouping the slice definitions by something other than the Ubuntu release would become more and more unsustainable and error prone. This is because it is much easier to copy the same slice definitions files across different branches than it is to maintain a multi-release slice definitions file, where the diverging contents grow endlessly with every new Ubuntu release.
2. Package Version and Slice Compatibility
Observation 2:
Package version changes can affect slice compatibility. For example, consider the libclone-perl library, version 5.38, with the file path /usr/lib/x86_64-linux-gnu/perl5/5.38/Clone.pm. When the package version updates, the file path changes accordingly, causing the slice to no longer function as expected.
Suggestion 2:
Introduce support for package version variables in the YAML files. By using placeholders like ${VERSION:#.#}, we could dynamically extract version numbers (e.g., 5.38) and create resilient slices that adapt to package version changes. This approach would minimize the need for manual updates when packages are updated.
Package versions don't typically change in stable releases - only patches occur. If there's such a corner case, those can be covered with globs. E.g. /usr/lib/x86_64-linux-gnu/perl5/5.*/Clone.pm.
Package pinning has come up a few times already and we're considering implementing support for snapshots in the future: https://github.com/canonical/chisel/issues/154.
Automation of Slice Version Checking
Finally, we could significantly enhance slice maintenance by automating version checking. If all slices included declarations of all files and dependencies within the slice file, we could run nightly tests against the slices using tools like apt-file list and apt-cache depends. This process would detect version changes without any modifications to the files or dependencies, automatically update the supported version list, and generate reports for any slices that require updates.
Yes, we do some of this already. Check: https://github.com/canonical/chisel-releases/blob/main/.github/workflows/install-slices.yaml#L17
If a slice definition breaks due to an unusual upstream update, we'll know about it.
Thank you for your time and consideration.
Thank you very much for engaging! More a more dynamic exchange we'd be happy to have you join the community!
Good Afternoon,
I discovered Ubuntu Chisel last year, and it has been a project that greatly interests me. After significant research and experimentation, I'm eager to migrate most of the container applications my company uses to Ubuntu Chisel containers.
My initial project involves building a WordPress container, which requires PHP, MySQL, and NGINX. However, I noticed that many of the necessary slices for these components do not yet exist. I've completed about 20 out of the 50 slice files needed, but I'm concerned about the long-term workload associated with package versioning in this endeavor.
I believe that for wider adoption of this project, we need to address the substantial work involved in the current slice implementation. I see this issue comprising two main elements, which I'd like to outline with observations and suggestions:
1. OS Version-Specific Slice Databases
Observation 1:
The slice database is currently specific to each OS version (e.g., 24.04, 24.10), even though many slices are compatible across different versions. This setup appears to rely on slice maintainers manually porting each slice between OS versions, which is time-consuming and inefficient.
Suggestion 1:
By adding an application versioning property to the YAML slice files, we could unify the slice database and enable slices to work across multiple OS and package versions. This change would reduce duplication and simplify maintenance, facilitating broader compatibility without the need for manual porting.
2. Package Version and Slice Compatibility
Observation 2:
Package version changes can affect slice compatibility. For example, consider the libclone-perl library, version 5.38, with the file path /usr/lib/x86_64-linux-gnu/perl5/5.38/Clone.pm. When the package version updates, the file path changes accordingly, causing the slice to no longer function as expected.
Suggestion 2:
Introduce support for package version variables in the YAML files. By using placeholders like ${VERSION:#.#}, we could dynamically extract version numbers (e.g., 5.38) and create resilient slices that adapt to package version changes. This approach would minimize the need for manual updates when packages are updated.
Automation of Slice Version Checking
Finally, we could significantly enhance slice maintenance by automating version checking. If all slices included declarations of all files and dependencies within the slice file, we could run nightly tests against the slices using tools like apt-file list and apt-cache depends. This process would detect version changes without any modifications to the files or dependencies, automatically update the supported version list, and generate reports for any slices that require updates.
Conclusion
Implementing these suggestions could greatly reduce the maintenance overhead and improve the scalability of Ubuntu Chisel containers. I believe these changes would encourage broader adoption and streamline the development process.
While I might not be able to contribute much on the slice programming side, I am eager and willing to assist with testing, validation, and building the slices in the proposed format. I'm also willing to help migrate the existing slices to the new format to support these enhancements.
I'm keen to start a discussion on how we can improve the project in these areas and would appreciate any feedback or ideas from the community.
Thank you for your time and consideration.