-
-
Notifications
You must be signed in to change notification settings - Fork 159
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
Labels
enhancement
New feature or request
Comments
I like it too, thanks for the suggestion, and feel free to do it as part of #543 if you feel like it 🙏 |
Should I add the |
I would say probably all @Arsen6331 |
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
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:
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
Describe alternatives you've considered
The
ConventionalExtension()
method could be added directly to thePackager
interface, but that would be a breaking change. Also, an extension argument could be added toRegisterPackager()
, but that would be a breaking change as well.Search
Code of Conduct
Additional context
No response
The text was updated successfully, but these errors were encountered: