Alpine Package Keeper (apk) format support

[Knetic]

After making #1042, I decided to give it a crack. This PR adds an "apk" destination which works just like you'd expect; implementing Alpine Linux packages.

Just to list it out so it's easy to see, this PR supports the following things beside the usual "install files to the right places";

• Control scripts (preinstall, postupgrade, etc)
• Dependencies (like relying on another package to be installed before the current one)
• Package version/name/homepage/description (which are written to a special control file called .PKGINFO required by the format)
• I've tested this against each minor version of Alpine, and the packages produced work on all versions currently on Dockerhub (2.6+, all the way to latest, which is 3.3).

A few things to note (so you don't have to pick through the code to notice it);

• There are no tests. I'm not all that sure how one would even test this sort of thing without requiring docker. I looked through the spec folder, but didn't really understand it. If it helps, I can make a gist of the scripts and dockerfile I've been using to manually test it as I go.
• I haven't gotten to extracting from an APK, only making a package. Not sure if that feature is required - i personally never make packages from anything other than a dir.
• I know this is like 30 commits long, I haven't done any squashing. Not sure what the repo policy on that is.

[jordansissel]

I haven't read the code yet, nor tested, but let me respond to your concerns first --

There are no tests

I am OK with this. While having tests would be lovely, it is OK if you aren't sure how to write them! We can work on this iteratively. I suspect some folks manually testing this would be enough for me to be happy merging. I will try to test it myself also. :)

I haven't gotten to extracting from an APK, only making a package. Not sure if that feature is required

Not required. What you have (making a package) is great! We can always add "from APK" support in the future.

I haven't done any squashing. Not sure what the repo policy on that is.

I have no policy. 30 commits is fine with me :)

[subnetmarco]

Any chance we can move this forward? Can't wait to use it to create the official Kong Docker packages.

[jordansissel]

@thefosk I'd love to! I currently have a plethora of windows boxes, none of which can run Alpine linux due to a bug somewhere between Hyper-V and Alpine Linux (the boot from the 3.3.1 and 3.3.3 ISO both hang similar to reported here).

As I can't test this right now, I'd love feedback from Alpine users who can help this PR get some feedback on usage, bugs, etc.

[xiaods]

+1, testing it.

[tya]

+1

[jordansissel]

Tested using the alpine docker image:

% bin/fpm -s dir -t apk -n example $HOME/.zshrc
apk output does not currently sign packages. {:level=>:warn}
It's recommended that your package be installed with '--allow-untrusted' {:level=>:warn}
Created package {:path=>"example_1.0_noarch.apk"}

% docker run -v $PWD:/data:z -i -t alpine /bin/sh -c 'apk add /data/example_1.0_noarch.apk; ls -la /home/jls; apk del example'
Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
WARNING: Ignoring APKINDEX.5a59b88b.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.7c1f02d6.tar.gz: No such file or directory
(1/1) Installing example (1.0)
ERROR: Metadata for package example-1.0 is too long.
OK: 5 MiB in 12 packages
total 24
drwxrwxr-x    2 root     root          4096 Apr 27 08:29 .
drwxr-xr-x    3 root     root          4096 Apr 27 08:29 ..
-rw-r--r--    1 root     root         12567 Apr  9 00:20 .zshrc
WARNING: Ignoring APKINDEX.5a59b88b.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.7c1f02d6.tar.gz: No such file or directory
OK: 5 MiB in 11 packages

Looks like it worked!

I'm not sure what to test beyond this, but functionally it seems good (given my zero experience level with Alpine)

[subnetmarco]

Great news, thank you!

[Knetic]

Awesome! That's pretty similar to my tests, I tested a few init scripts and binaries together. I never observed that error ERROR: Metadata for package example-1.0 is too long., I'll look into it. I worked fairly hard to exactly match the apk format as the alpine tools generate it, but I may have added some extra padding somewhere or something.

@jordansissel Also just to put it out there, if you'd like I'm willing to field bugs and questions people may have on the APK support. But I don't really watch the fpm issue pages much - so if something comes up, feel free to at-me or email me or something.

[jordansissel]

@Knetic thank you much for the offer to help support folks as they play with the new apk support. Will ping you as appropriate via email ❤️

[freeseacher]

any news ?

[jordansissel]

@freeseacher about what? This was merged 5 months ago.

[freeseacher]

ou, sorry, i just read doc and did not find it. so i search for pull request and found that one.
so simply missed merged status.

[subnetmarco]

I confirm that docs are not updated.

[suntong]

This PR adds an "apk" destination which works just like you'd expect;

Thanks a lot @Knetic, fpm is the fist place I looked when searching for this feature. Glad that it was provided so many years ago.

Now,

... this PR supports the following things beside the usual "install files to the right places";

• Control scripts (preinstall, postupgrade, etc)
• Dependencies (like relying on another package to be installed before the current one)
• Package version/name/homepage/description (which are written to a special control file called .PKGINFO required by the format)
• I've tested this against each minor version of Alpine, and the packages produced work on all versions currently on Dockerhub (2.6+, all the way to latest, which is 3.3).

I would very much like to know how the above can be achieved, i.e., adding preinstall, postupgrade control scripts and dependencies when doing the apk packaging, as I want to automate the apk creating when I'm packaging dbab --

https://salsa.debian.org/debian/dbab

Thanks!

[suntong]

I would very much like to know how the above can be achieved,

OMG, it is much simpler than I thought --

$ fpm --verbose -s deb -t apk ../dbab_1.5.0-1_all.deb
Doing `require 'backports'` is deprecated and will not load any backport in the next major release.
Require just the needed backports instead, or 'backports/latest'.
Setting workdir {:workdir=>"/tmp", :level=>:info}
deb field {"Version"=>"1.5.0-1", :level=>:info}
deb field {"Architecture"=>"all", :level=>:info}
deb field {"Section"=>"net", :level=>:info}
deb field {"Maintainer"=>"Tong Sun <[email protected]>", :level=>:info}
deb field {"Package"=>"dbab", :level=>:info}
deb field {"Homepage"=>"https://github.com/suntong/dbab", :level=>:info}
deb field {"Depends"=>"perl:any, dnsmasq, curl, dnsutils", :level=>:info}
Setting from flags: epoch= {:level=>:info}
Converting deb to apk {:level=>:info}
apk output does not currently sign packages. {:level=>:warn}
It's recommended that your package be installed with '--allow-untrusted' {:level=>:warn}
Created package {:path=>"dbab_1.5.0-1_all.apk"}

So what's only remains is how to add preinstall, postupgrade control scripts.

[Knetic]

Hey @suntong , the control scripts and dependencies are specified like this;

    --after-install FILE          A script to be run after package installation
    --before-install FILE         A script to be run before package installation
    --after-remove FILE           A script to be run after package removal
    --before-remove FILE          A script to be run before package removal
    -d, --depends DEPENDENCY      A dependency. This flag can be specified multiple times. Value is usually in the form of: -d 'name' or -d 'name > version'

(taken from the wiki which lists out the usage of fpm).

[suntong]

Thanks @Knetic, I was at the wiki, but didn't see apk in the Target package types, so I didn't read further, :(. thanks for helping!

[suntong]

Hi @Knetic, would it be possible for command line --depends setting to overwrite that read from .deb files?

I tried
fpm --verbose -s deb -t apk --depends 'dnsmasq,perl,curl,bind-tools' ../dbab_1.5.0-1_all.deb

but am still getting:

deb field {"Depends"=>"perl:any, dnsmasq, curl, dnsutils", :level=>:info}

and when I tried to install it, I got:

==> docker: ERROR: unsatisfiable constraints:
    docker:   perl:any (missing):
    docker:     required by: dbab-1.5.0-1[perl:any]
    docker:   dnsutils (missing):
    docker:     required by: dbab-1.5.0-1[dnsutils]

Thanks for your consideration.