RFC on adding an

nfpm

backend that can generate

deb

,

rpm

,

apk

, and

archlinux

packages: https://docs.google.com/document/d/1b2ZvP_Ol6bOURHBaZYOD8gxixxHpV22S_zKiHKZw9iY/edit?usp=sharing

I assume the ongoing PyCon is distracting.. I can offer an eye later today for my cents 😉

Yes please! My sense says your cents are very valuable!

I skimmed the doc real quick and have some early preliminary questions. Regardless of packaging tool used, the input/output pair would be ~the same I’d imagine. So the difference being focused on the how. Differing features and methodologies may affect the interface to some degree, but to me it would make sense to have one common target type for packaging (likely per package type), that share a high level generic interface. Then you get to pick which backend implementation you want to apply along with that. Each implementation may register custom plugin fields to expose implementation specific features that are not part of the common generic interface that all implementations must support. Does this make sense to you? (at first I thought it was a great idea, after having typed this down I start to second guess how big impact it would actually have compared to just dedicated targets per backend implementation.. )

So, if I understand what you're saying: For

deb

packages: • we would use the

debian_package

target, but the

nfpm

backend would register different fields on that target than if you enabled the

debian

backend. ◦ The

debian_backend

currently registers 4 fields:

sources

,

symlinks

,

install_prefix

,

packages

. Of those I might be able to use the

sources

field - but the help text is all wrong for the

nfpm

backend which generates the

CONTROL

file instead of requiring the user to write it.

the last remark is the killer

And I just looked at

fpm

options for

deb

, and I'm not sure how much it would share with

nfpm

. https://fpm.readthedocs.io/en/latest/packages/deb.html The options for

fpm

are confusing imo, which is part of why I looked for an alternative (that and ruby - ick, plus the other reasons listed in the proposal).

yea, my tack was about not exposing too much of the how in the inteface, trying to focus more on the what. but regardless of that goal, you should of course be able to have a mixed setup using either or both in one repo at the same time

Thank you!

left a few comments, but by and large it looks sane to me. There are a few cases with multiple source/dependency fields that may break new ground but apart from that seems pretty straight forward.

Thank you! I'll check out your comments shortly