3 ms·

This is a huge problem for Linux distributions. I've been thinking of trying to open source a project (it's a web application simulator) that we have internally

This is a huge problem for Linux distributions. I've been thinking of trying to open source a project (it's a web application simulator) that we have internally, that is built using Javascript/NodeJS and Python/Flask. While the mechanics of slapping a GPLv3 license on the code we wanted to publish were fairly straightforward, severe problems arose when we wanted to package it for distribution with an OS like Debian. The application is a web app that uses both Node and Python, and the complexities packaging it were overwhelming. For now we planning on releasing it as a container image. I'm not fan of doing this, but it seemed like a solution we conceivably implement with the time and resources we had available to us.

zbentley 3y ago
If you ever revisit that decision, check out FPM. It can shave off a few of the rough edges related to packaging: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
- johnny22 3y ago
  maybe im reading it wrong, but it sounds like they wanted it to be able to be included in the distribution and not just make a package for it. If that's the case, fpm wouln't help. They'd still have to split out all their deps and get them packaged and aso hope the deps don't collide with existing deps version wise.
tupolef 3y ago
Please just provide a list of dependencies with min/max versions, one for Build and one for Usage. Then provide a detailed example of the config files, a systemd unit file, and maybe some config examples for the 3 main webservers. People will then deal with it. The target for such a project is not a noob user and it's more ressource friendly and it help people to understand how to debug the app and how it works. I'm testing around 10 new tools every week and I hate when the project page only gives me a docker/flatpack/snap solution, I always find a way to install it raw without any indications, and it's painful.

zbentley 3y ago

If you ever revisit that decision, check out FPM. It can shave off a few of the rough edges related to packaging: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

johnny22 3y ago
maybe im reading it wrong, but it sounds like they wanted it to be able to be included in the distribution and not just make a package for it. If that's the case, fpm wouln't help. They'd still have to split out all their deps and get them packaged and aso hope the deps don't collide with existing deps version wise.

tupolef 3y ago

Please just provide a list of dependencies with min/max versions, one for Build and one for Usage. Then provide a detailed example of the config files, a systemd unit file, and maybe some config examples for the 3 main webservers. People will then deal with it. The target for such a project is not a noob user and it's more ressource friendly and it help people to understand how to debug the app and how it works. I'm testing around 10 new tools every week and I hate when the project page only gives me a docker/flatpack/snap solution, I always find a way to install it raw without any indications, and it's painful.