search

dawidd6 / action-debian-package

:gear: A GitHub Action for building Debian packages
MIT License
25 stars 8 forks source link

run apt-get without -t #64

Closed SebKuzminsky closed 1 year ago

SebKuzminsky commented 1 year ago

Hi there, this PR is my proposed fix for #63.

waja commented 1 year ago

Hmmm... maybe I'm wrong, but https://github.com/dawidd6/action-debian-package/actions/runs/3401192905/jobs/5662350868 looks not so good.

dawidd6 commented 1 year ago

Yea, this is what I was expecting will happen. Backports building is currently broken. Don't know if I should revert this or find some other solution to it...

SebKuzminsky commented 1 year ago

Hmm, yes, I see the problem with backports... Bummer.

The build error that prompted this change is described in #63, and demonstrated in this action run: https://github.com/LinuxCNC/mesaflash/actions/runs/3401503804/jobs/5656655540

The problem is caused by a libc6 update available in bullseye-updates but not yet in bullseye itself. The debian:bullseye image is built with bullseye-updates enabled, so the installed version of libc6 is from bullseye-updates (not bullseye). libc6-dev has a versioned dependency on the matching libc6, so apt-get install -t bullseye libc6-dev tries to install the earlier libc6-dev, which fails. apt-get install libc6-dev (without specifying a -t) picks the correct libc6-dev from bullseye-updates.

But as shown in the build failure helpfully pointed to by @waja above, running apt-get without -t fails when building on *-backports (because backports has a lower priority than the "parent" distro).

I've looked a bit at the apt package dependency resolver and I must admit I don't see good solution here. I can think of two gross hacks we could try:

  1. Try apt-get -t first (so -backports will work), and if that fails try it again without -t (so builds in non-backports containers whose images were built during a versioned-dependency transition in -updates will work).
  2. If the requested dist (e.g. "bullseye" or "bullseye-backports") has a matching "${dist}-updates", use -t ${dist}-updates. If it does not have an -updates version, use the regular -t ${dist}. The command apt-get indextargets --format='$(CODENAME)' | grep -q ${imageTag}-updates returns true for bullseye (because there's a bullseye-updates) and false for bullseye-backports (because there's not a bullseye-backports-updates).

Thoughts?

dawidd6 commented 1 year ago

Either first or second solution works for me.

SebKuzminsky commented 1 year ago

Here's an attempt at the first option (only because it seemed easier to implement for someone like me who doesn't know Javascript): https://github.com/SebKuzminsky/action-debian-package/commit/6384d3de32e2658d3df285b0d484cf34387c0c27

It gets past the action-debian-package test case where it broke before, and it works for me in my application despite the ongoing bullseye/bullseye-updates version skew.

But it fails in a different action-debian-package test, not sure if that has anything to do with this change: https://github.com/SebKuzminsky/action-debian-package/actions/runs/3414551443/jobs/5682658379

I would welcome debugging help here.