From f89e16fb4656d4a9e3f76d0b77c25d2fc3c9f215 Mon Sep 17 00:00:00 2001 From: Moritz Kirchner Date: Tue, 26 May 2026 21:44:09 +0200 Subject: [PATCH] Update package-sources.md I think part of it is touched in different places and I wasn't sure which place is the best, I just thought: if one reads about packages this description should be there. I added the information to the orginal release.md where I would have placed it because it should be information available in case somebody makes a release, but due to the new very nice structure this might stay here, or not, depending on how you feel is best. --- docs/explanation/package-sources.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/explanation/package-sources.md b/docs/explanation/package-sources.md index aa891bf..78a6ff3 100644 --- a/docs/explanation/package-sources.md +++ b/docs/explanation/package-sources.md @@ -57,6 +57,27 @@ Packages with native sources are used when: - The source code is developed and maintained by the Garden Linux developers, so Debian does not package it +# Package Repository Conventions +## naming +If a package repository is called package-* and if it has the build.yml workflow then it will be built every night. Sometimes one doesn't want that and then the repository name is prefixed differently, most likely bp-package-something. + +## branches within package-* repositories +Each package repository should have `rel-*` branches that relate to the Garden Linux version for which this package is being built. This is to ensure the correct versions are being built with the correct dependencies for the correct Garden Linux versions. For example `package-openssh` could be built in one version for Garden Linux 1877 and another version for Garden Linux 2150. This means there should be branches called `rel-1877` and `rel-2150`. Packages should never be built main. Although it is a convention and not enforced. + +Also important on the `rel-*` branches is the `.container` file + +## .container file +which includes the hash of the Garden Linux repo at the day of the release of the Major Garden Linux release, for example: +```$ wget -qO- "https://raw.githubusercontent.com/gardenlinux/repo/refs/tags/1877.0/.container" +ghcr.io/gardenlinux/repo-debian-snapshot@sha256:0348e829222f0e62c61cb68e630f1766b62e4311303bc35b02cbd5c62a98abef +$ wget -qO- "https://raw.githubusercontent.com/gardenlinux/repo/refs/tags/1877.1/.container" +ghcr.io/gardenlinux/repo-debian-snapshot@sha256:0348e829222f0e62c61cb68e630f1766b62e4311303bc35b02cbd5c62a98abef +$ wget -qO- "https://raw.githubusercontent.com/gardenlinux/repo/refs/tags/1877.2/.container" +ghcr.io/gardenlinux/repo-debian-snapshot@sha256:0348e829222f0e62c61cb68e630f1766b62e4311303bc35b02cbd5c62a98abef``` +it is crucial to pin down the build environment in that way with which the package is being built. Otherwise packages from debian testing at the point of time of when a package is being built are being used. Which might even mean a package doesn't build anylonger without a code change or doesn't work within the same Garden Linux release any longer for example there could be a different `libc` version in debian testing at that point as opposed to at release time. + + + ## Related Topics