Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle packaging formats with non-distinct file extensions #546

Closed
2 tasks done
Elara6331 opened this issue Sep 12, 2022 · 5 comments · Fixed by #543
Closed
2 tasks done

Handle packaging formats with non-distinct file extensions #546

Elara6331 opened this issue Sep 12, 2022 · 5 comments · Fixed by #543
Assignees
Labels
enhancement New feature or request

Comments

@Elara6331
Copy link
Contributor

Elara6331 commented Sep 12, 2022

Is your feature request related to a problem? Please describe.

When implementing #543, I imported it into a local clone of goreleaser in order to test it. I noticed that it created a file with the .archlinux extension. The issue is that the packager was registered as "archlinux", which I did because Arch Linux doesn't have a distinct package extension, and just uses .tar.zst, which is the extension for any TAR file compressed with Zstandard.

Describe the solution you'd like

I think the best solution would be to add a new interface that looks something like this:

type PackagerWithExtension interface {
	Packager
	ConventionalExtension() string // Returns an extension like .rpm or .pkg.tar.zst
}

This way, a breaking change is avoided, while providing a type-safe way to check the extension. To check the extension, you'd do something like

if packager, ok := packager.(nfpm.PackagerWithExtension); ok {
	ext := packager.ConventionalExtension()
	// do something with ext
}

Describe alternatives you've considered

The ConventionalExtension() method could be added directly to the Packager interface, but that would be a breaking change. Also, an extension argument could be added to RegisterPackager(), but that would be a breaking change as well.

Search

  • I did search for other open and closed issues before opening this.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Additional context

No response

@Elara6331 Elara6331 added the enhancement New feature or request label Sep 12, 2022
@djgilcrease
Copy link
Contributor

I like this, as long as @caarlos0 is good with this I say add it as part of #543

@caarlos0
Copy link
Member

I like it too, thanks for the suggestion, and feel free to do it as part of #543 if you feel like it 🙏

@Elara6331
Copy link
Contributor Author

Should I add the ConventionalExtension() method to all packagers as part of my PR or just Arch?

@caarlos0
Copy link
Member

I would say probably all @Arsen6331

@Elara6331
Copy link
Contributor Author

Done

caarlos0 added a commit that referenced this issue Oct 15, 2022
* feat: add support for Arch Linux packages

* test: Add initial tests

* test: Increase coverage by modifying example info

* test: Add test for ArchLinux.ConventionalFileName()

* docs: Return error if package name is invalid

* fix: Make empty name invalid

* fix: Add replaces field to .PKGINFO generator

* test: Add additional tests

* test: Test for added replaces field

* docs: Add more comments

* style: Run gofumpt

* fix: Handle errors as recommended by linter

* fix: Allow changing the pkgbase

* style: Resolve semgrep findings

* docs: Change docs to reflect new Arch Linux packager

* docs: Fix spelling mistake in comment

Co-authored-by: Dj Gilcrease <digitalxero@gmail.com>

* docs: use aspell to fix all spelling mistakes

* feat: Handle packaging formats with non-distinct file extensions as described in #546

* fix: Add newline to generated .INSTALL file

* fix: Take into account provided info for non-symlink files

* docs: Fix names for arch-specific scripts in documentation

* fix: Only consider files with the correct packager field

* fix: Use correct scripts field for post_remove script

* test: Implement archlinux acceptance tests

* test: Add archlinux to acceptance_test.go

* test: Add archlinux to github test matrix

* test: Use updated build.yml from main branch

* Fix ConventionalExtension() for apk

* fix: Take epoch value into account

* fix: Add arm5 and arm6 architectures

Co-authored-by: Dj Gilcrease <digitalxero@gmail.com>
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
caarlos0 pushed a commit to goreleaser/goreleaser that referenced this issue Oct 15, 2022
<!--

Hi, thanks for contributing!

Please make sure you read our CONTRIBUTING guide.

Also, add tests and the respective documentation changes as well.

-->


<!-- If applied, this commit will... -->

This PR upgrades nFPM to v0.20.0, and integrates the new
`ConventionalExtension` method to use the correct extension for the
packaging format that is being used.

<!-- Why is this change being made? -->

Currently, goreleaser uses the name of the format to determine the
extension. This has worked fine, but with the introduction of Archlinux
packages, goreleaser has to handle packages with extensions that don't
match the name of the format, since Archlinux uses `.pkg.tar.zst` as the
extension.

<!-- # Provide links to any relevant tickets, URLs or other resources
-->

goreleaser/nfpm#546
goreleaser/nfpm#543
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants