Skip to content

request: target official package generation tools #2139

@mcandre

Description

@mcandre

fpm's ambituous goal of generating packages from scratch, unfortunately has the consequence of inviting bitrot.

Even if fpm fully implements every possible metadata option for a package type, perfectly, then the package system eventually ends up breaking compatibility later. At that point, we require laborious development effort to revive our low level implementation. Often multiple times, with each upstream breaking change.

I think this is the same approach by nfpm, goreverser, etc.

As a developer, I too, make this mistake. I don't like to depend on shelling out, or additional dependencies, whenever possible. But there is a cost to trying to reimplement these low level details. Perfect Ruby, Go, and Rust API's do not exist, for every package management system.

That's why I recently pivoted to raising the abstraction level from API's, for rockhopper.

https://github.com/mcandre/rockhopper

The first few versions of rockhopper raise the abstraction layer up to containers, where it's trivial to provision and use per-distro package generation tools. Breakages will still occur, but most of them are automatically resolved by the distro's own build tools. So we mitigate let's say 90% of breaking changes.

Planning to provide an option for host shell package build commands, as a way to fold macOS into the mix.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions