search

2m / arch-pkgbuild-builder

Arch Linux PKGBUILD GitHub builder action
https://github.com/marketplace/actions/arch-linux-pkgbuild-builder-action
35 stars 24 forks source link

Doesn't handle optional dependencies gracefully #34

Closed vchernin closed 3 years ago

vchernin commented 3 years ago

I tried this out for building the electron package, and it seems to work. However I had to manually set the optional dependencies to hard dependencies to get it past the dependencies stage.

Is this intended behaviour? If it isn't working without the optional dependencies shouldn't the action detect that and try with those dependencies included?

With those dependencies not in optdepends: gives failure, source.

With those optional depedencies added to makedepends: gives success (at least past the other attempt), source.

2m commented 3 years ago

Hey, I am glad to hear you found this useful!

Yea, currently optdepends is filtered out in the logic that installs dependencies: https://github.com/2m/arch-pkgbuild-builder/blob/main/entrypoint.sh#L52

That is mainly because of a different format of the list in there (colon and text after it). But this certainly can be improved to add support for optdepends.

I think it would be awesome if we could use some pkgbuild tool to parse the list of all dependencies from PKGBUILD and then use that for installation.

vchernin commented 3 years ago

Makes sense, thank you for clarifying that (and great work on this action!)

I was also wondering how exactly are dependencies managed. I know ubuntu 20.04 is used from github's ubuntu-latest, and then an arch container is used on top of that? I figured this meant the dependencies would all be the latest things like arch usually does, but it seems some the things being downloaded like gn-0.1731.5ed3c9cc-1 are from 2020?

Is there a way to get a newer arch image or something? All the packages that I've looked at are older than expected, and they definitely seem like arch packages since they're .zst.

I can also just open a new issue for this second problem if you prefer that.

2m commented 3 years ago

This action is using the following docker image: https://hub.docker.com/r/martynas/archlinux But yea, it has not been rebuilt for quite a while (it uses pacakges from Arch Linux Archive from the time it was built). I'll try rebuilding it now. For some reason automatic rebuilds stopped working.

vchernin commented 3 years ago

Awesome, thank you! I can try to help if there's anything useful I can do there.

2m commented 3 years ago

Sure! If you can take a look at dependency parsing logic and improving that to handle optdepends, that would be neat!

vchernin commented 3 years ago

BTW It seems like the name of the docker hub URL for arch changed, maybe that's why automatic rebuilds stopped working. The link now is: https://hub.docker.com/r/archlinux/archlinux but the one in the readme is: https://hub.docker.com/r/archlinux/base

2m commented 3 years ago

Yup, good spot. Updated to the Dockerfile and the readme.

vchernin commented 3 years ago

I spent a while trying to get it working, eventually I realized something I should have immediately. The code that's used currently for make and regular packages only is actually able to look at one line.

If you clone the PKGBUILD like electron's you'll see some of the make and regular dependencies aren't on the outputed list.

grep -E 'depends|makedepends' PKGBUILD | \
        grep -v optdepends | \
        sed -e 's/.*depends=//' -e 's/ /\n/g' | \
        tr -d "'" | tr -d "(" | tr -d ")"

Outputs:

c-ares
ffmpeg
gtk3
libevent
libnghttp2
libxslt
minizip
clang
git
gn
gperf
harfbuzz-icu
http-parser

A lot of these are missing:

depends=('c-ares' 'ffmpeg' 'gtk3' 'libevent' 'libnghttp2' 'libxslt' 'minizip'
         'nss' 're2' 'snappy')
makedepends=('clang' 'git' 'gn' 'gperf' 'harfbuzz-icu' 'http-parser'
             'java-runtime-headless' 'jsoncpp' 'libnotify' 'lld' 'llvm' 'ninja'
             'npm' 'pciutils' 'pipewire' 'python2' 'wget' 'yarn')

I can only assume the reason I had any luck building is because chromium/electron is somehow smart enough to figure it out? Or maybe something else is downloading the packages somewhere else in this file and I didn't realize?

Maybe later I'll try to find a more straightforward way of parsing all of the packages, since that's probably easier than me trying to reuse something that I clearly didn't fully understand.

2m commented 3 years ago

Yup, good catch. I think we have just been lucky.

Once this is fixed, we can add your repo to the CI tests (https://github.com/2m/arch-pkgbuild-builder/blob/main/.github/workflows/ci.yml#L30-L35) so this is tested and it does not break in the future.

vchernin commented 3 years ago

I don't think adding the electron repo is the best choice for CI as it is among the slowest things to compile. There's probably a much better choice somewhere that still tests the issue.

I still haven't been able to get electron compiling with the arch PKGBUILD, so I think I'm missing something else entirely.

It might be a while before I look into this again, but hopefully some day.

Thank you again for your help :)

2m commented 3 years ago

I changed parsing dependencies from .SRCINFO in #35. This way all optdepends are installed as well. So this at least solves the issue with optional dependencies.