feat: add support for Arch Linux packages

[Elara6331]

This PR adds support for Arch Linux packages.

Like the previous PR (#141), this one generates .PKGINFO, .INSTALL, and .MTREE files.

Unlike that PR, this one compresses the package with a pure-Go Zstandard implementation, which conforms with the new standard for Arch packages.

I have successfully been able to install packages generated by this code, so it works, but there are no tests, so I am leaving it as a draft until I add tests and more comments to it.

Closes #133 Closes #546

[caarlos0]

amazing @Arsen6331! Let me know if you need any help!

[codecov[bot]]

Codecov Report

Merging #543 (31ab006) into main (1a66c73) will increase coverage by 0.68%. The diff coverage is 73.37%.

@@            Coverage Diff             @@
##             main     #543      +/-   ##
==========================================
+ Coverage   69.31%   70.00%   +0.68%     
==========================================
  Files          20       21       +1     
  Lines        2581     3087     +506     
==========================================
+ Hits         1789     2161     +372     
- Misses        614      706      +92     
- Partials      178      220      +42     

Impacted Files	Coverage Δ
apk/apk.go	72.12% <0.00%> (-0.42%)	:arrow_down:
deb/deb.go	71.16% <0.00%> (-0.27%)	:arrow_down:
internal/cmd/package.go	0.00% <0.00%> (ø)
internal/cmd/root.go	0.00% <ø> (ø)
nfpm.go	86.56% <ø> (ø)
rpm/rpm.go	68.88% <0.00%> (-0.52%)	:arrow_down:
arch/arch.go	74.40% <74.40%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[Elara6331]

I've added the tests and comments, and fixed what the linter suggested.

[caarlos0]

Thanks, @Arsen6331 🚀

could you make the changes to the docs as well? they live in the www folder.

[Elara6331]

could you make the changes to the docs as well? they live in the www folder.

Sure

[Elara6331]

I've changed the docs

[Elara6331]

Implement signed packages wiki.archlinux.org/title/DeveloperWiki:Package_signing Appears to create a .sig file to live outside the package?

Yeah, it requires a separate file and I don't know how to implement that with the current API.

[djgilcrease]

Yeah, it requires a separate file and I don't know how to implement that with the current API.

Just make a doSign method that writes the file alongside the package if the info.ArchLinux.Signature.KeyFile is not empty.

[Elara6331]

Just make a doSign method that writes the file alongside the package if the info.ArchLinux.Signature.KeyFile is not empty.

The issue with that is that the Package() method of the Packager interface takes an io.Writer and writes to it. The packager doesn't actually control file creation.

[caarlos0]

Just make a doSign method that writes the file alongside the package if the info.ArchLinux.Signature.KeyFile is not empty.

The issue with that is that the Package() method of the Packager interface takes an io.Writer and writes to it. The packager doesn't actually control file creation.

ah yes, seems like one more thing we'll have to change...

that said, maybe its for the best to actually break API compat for both this and #546?

[djgilcrease]

I am ok skipping signing for now so we can take a little time and design the build/sign API.

[caarlos0]

I am ok skipping signing for now so we can take a little time and design the build/sign API.

yeah, sounds good

[Elara6331]

I've looked at the existing acceptance tests and I understand what they do, but I have no idea where to start in terms of implementing them for Arch. Can someone point me in the right direction?

[caarlos0]

@Arsen6331 If I'm not missing anything:

• add arch here: https://github.com/goreleaser/nfpm/blob/e6f966fa6f3d94c5fddb4decc14aa9294a4f6d8a/acceptance_test.go#L22
• create the dockerfiles and edit the goreleaser config files here: https://github.com/goreleaser/nfpm/tree/main/testdata/acceptance

you can start with the min and simple to get a handle on how it works... it is a bit complex - mainly because properly testing all this is complex, but once you get a hand of it it will hopefully make more sense...

[Elara6331]

On Arch, packages cannot write to /usr/sbin as it is a symlink to /usr/bin, and pacman does not follow the symlink and therefore refuses to write to it. This is intentional behavior and not a bug in pacman. The complex acceptance test tries to add a file to /usr/sbin. How should I handle this? I could add an if statement in TestCore() that uses an Arch-specific file for the complex test. Would that be an acceptable solution?

[Elara6331]

Oh, I just realized I could also do this if it's better:

- src: ./testdata/fake
  dst: /usr/sbin/fake
  file_info:
    mode: 04755
  packager: deb
- src: ./testdata/fake
  dst: /usr/sbin/fake
  file_info:
    mode: 04755
  packager: rpm
- src: ./testdata/fake
  dst: /usr/sbin/fake
  file_info:
    mode: 04755
  packager: apk
- src: ./testdata/fake
  dst: /usr/bin/fake
  file_info:
    mode: 04755
  packager: archlinux

I think both solutions are a bit ugly, but I don't see any other solution.

[caarlos0]

I don't remember why we write to sbin to be honest, maybe someone else does? cc\ @goreleaser/nfpm

if not, imho, we can change it to /usr/bin.

if there's a reason, I would probably create a complex test config just for arch... probably...

[djgilcrease]

I kind of like the complex config for the complex test as it shows what you may need to do

- src: ./testdata/fake
  dst: /usr/sbin/fake
  file_info:
    mode: 04755
  packager: deb
- src: ./testdata/fake
  dst: /usr/sbin/fake
  file_info:
    mode: 04755
  packager: rpm
- src: ./testdata/fake
  dst: /usr/sbin/fake
  file_info:
    mode: 04755
  packager: apk
- src: ./testdata/fake
  dst: /usr/bin/fake
  file_info:
    mode: 04755
  packager: archlinux

[Elara6331]

I've implemented the acceptance tests. I added only amd64 to acceptance_test.go for Arch because Arch only officially supports x86_64. This means that the official docker image only works on amd64. However, we should still support the unofficial architectures because they're used very often, especially the armv7 and arm64 ones. I don't know how to proceed with that.

[Elara6331]

There is this multi-architecture image: lopsided/archlinux, which supports amd64 and all the ARM variants, but it doesn't contain things like grep, which are used by the acceptance tests.

[Elara6331]

There also seems to be a devel tag on that image, which has the base-devel group installed, so it has all the tools I need. That one should work, but then there's still no way to test 386.

[caarlos0]

I've implemented the acceptance tests. I added only amd64 to acceptance_test.go for Arch because Arch only officially supports x86_64. This means that the official docker image only works on amd64. However, we should still support the unofficial architectures because they're used very often, especially the armv7 and arm64 ones. I don't know how to proceed with that.

I would say that, at least for now, we can go with the official support only...

[Elara6331]

Ok, in that case, the acceptance tests are finished and pass. I did test them locally for both amd64 and the ARM variants, and they all pass there too.

[Elara6331]

Should I add archlinux to the pkgFormat field in .github/workflows/build.yml?

[caarlos0]

Should I add archlinux to the pkgFormat field in .github/workflows/build.yml?

yes, please!

Ok, in that case, the acceptance tests are finished and pass. I did test them locally for both amd64 and the ARM variants, and they all pass there too.

awesome!

[Elara6331]

Done

[Elara6331]

I could also try to make a PR against https://github.com/goreleaser/goreleaser that integrates these changes and can be merged once they make it into a release.

[caarlos0]

I could also try to make a PR against https://github.com/goreleaser/goreleaser that integrates these changes and can be merged once they make it into a release.

if you feel like it, go for it! If not, I can do it as well, no issues :)

[Elara6331]

I went through a bunch of PKGBUILDs on the AUR to see if I missed anything and implemented all of it.

[caarlos0]

I'll review this again today and see that we have it merge soon! 🙏 Sorry for the delay, had a crazy couple of weeks :P