Hi Krumelmonster and Simon, On Sat, 2024-02-10 at 12:02 +0100, Simon Josefsson wrote: > Krumelmonster <krumelmonster@zoho.com> writes: > > I would like to see podman>=4.4 make it into bookworm backports so the > > excellent quadlet feature would become available in debian stable. I'm > > inexperienced in debian packaging and gave up on my first attempt in > > creating this backport due to the sheer number of (indirect) > > dependencies missing in bookworm. > > > > Only after that have I learned about dh-make-golang but it is unclear > > to me whether or how I could use it to create the backports. > > > > Has someone looked into backporting podman before and where there issues? > > Are there any instructions on how to backport go packages in > > particular? What could be my starting point for attempting this? > > > > I would be very happy if someone else took the time to create the > > backport but it is important enough to me to attempt the backport > > myself and ask for sponsorship should it succeed. In that case, any > > advice would be welcome. > > Hi. I'm a go packaging newbie, but would also like to see this. I tend > to install unofficial podman (e.g., [1]) when the available podman is > too old, and working on official backports could help. > > I think you can simply try to build the current podman packages from > testing in a bookworm chroot, and then fix whatever breakage there is. > Most likely you will need to backport a number of reverse dependencies > to get podman to build. There is no need to use dh-make-golang which is > used to create a new package. I'm happy to help, but my spare cycles to > work on Go packages are stocastic and limited. On the one hand, backporting golang packages is relatively easy, because most of the golang packages in Debian simply contain the source required to build other golang packages so the risk of breaking a stable system is low. On the other hand, there tend to be a _ton_ of golang libraries when you look at the dependencies for a package like src:libpod. Backport policy[1] requires that only versions of packages in testing can be backported. This means there shouldn't be any need to create new packages; rather, you can (most of the time) just do (as a very simple example) a `dget <url/to/testing/version.dsc> && dch --bpo && debuild` in the appropriate environment (ie, a bookworm chroot/container/VM). Packages maintained within the Go Packaging Team tend to follow DEP14[2] for package git repos. So, let's take a quick look at the top-level dependencies missing from bookworm -- aka, roughly how much work will backporting be? For src:libpod 4.9.2+ds1-2, trying to use `git-buildpackage` to build the package for bookworm I get the following: > The following packages have unmet dependencies: > pbuilder-satisfydepends-dummy : Depends: golang-github-checkpoint-restore-checkpointctl-dev which is a virtual package and is not provided by any available package > Depends: golang-github-checkpoint-restore-go-criu-dev (> 6) but 5.3.0-2 is to be installed > Depends: golang-github-containers-buildah-dev (>= 1.33.5) but it is not going to be installed > Depends: golang-github-containers-common-dev (>= 0.57.4) but it is not going to be installed > Depends: golang-github-containers-image-dev (>= 5.29.2~) but it is not going to be installed > Depends: golang-github-containers-storage-dev (>= 1.51) but 1.43.0+ds1-8 is to be installed > Depends: golang-github-containers-gvisor-tap-vsocks-dev which is a virtual package and is not provided by any available package > Depends: golang-github-coreos-stream-metadata-go-dev which is a virtual package and is not provided by any available package > Depends: golang-github-docker-go-plugins-helpers-dev which is a virtual package and is not provided by any available package > Depends: golang-github-opencontainers-selinux-dev (>= 1.11~) but 1.10.0+ds1-1 is to be installed > Depends: golang-github-vbauerster-mpb-dev (>= 8) but it is not going to be installed > Unable to resolve dependencies! Giving up... That's not too bad, but does indicate there will be a fair amount of work required. I know from prior experience that criu and the go-criu packages can be tricky to work with across major versions, so that might be a potential tripping point if it's not possible for src:libpod to build/work with v5 of criu that's in bookworm. My recommendation would be for you to fully determine all the necessary packages required to build src:libpod 4.9.2+ds1-2 in bookworm. You'll have to start at the top, and then for each level of dependencies figure out which ones are missing or too old and recurse down until you find all the dependencies that are missing. You'll end up with a tree diagram, with src:libpod as the root node. Once you've done that, and also verified that the newer version of podman builds and behaves properly in bookworm, then you can start requesting sponsorship of the backport packages. You don't want to directly jump in and start requesting sponsorships because you might find an insurmountable issue part way through, which will leave "orphaned" packages in bookworm-backports and also waste the ftpmaster team's limited time, as someone has to manually review each package that goes through BACKPORTS-NEW. With that being said, I'd be willing to help sponsor the backporting of packages maintained within the Go Packaging Team if you decide you'd still like to take on the work of backporting podman for bookworm. Mathias [1] -- https://backports.debian.org/Contribute/ [2] -- https://dep-team.pages.debian.net/deps/dep14/
Attachment:
signature.asc
Description: This is a digitally signed message part