Limezy
commented
8 months ago I have had some troubles in the past using the same approach for the Photoprism package, but you are right, it makes more sense for small servers and seems to be the direction to go. For Photoprism, the issue was that the upstream container on which we took out the executable was based on another version of Debian...
Another issue is that we should be trusting the compilated executable upstream provider as we would be basically automatically downloading and executing an unknown program from internet - quite scary... moreover, should the upstream server be down or changing something it's another source of breaking the package, whereas the current design only needs the GitHub repo to be existing and GitHub not to be down.
It was already discussed among the Yunohost packagers that we could have a kind of "compilation farm" that would compile these programs for us (just like the CI is already doing for tests) and from which we could download "trusted" package. I like more that version but it's very far from being implemented yet.
Moreover my time ressources are rather limited so I won't invest time on a secondary package that already works (and on which I already spent way too much time to be honest !)
However, should you want to try a PR based on your idea I'll test it and merge it with pleasure.
for now, the installer and upgrader compiles Dex, which is heavy on resources
but we can instead extract the binary using container image, (like how the vaultwarden's package does), so no need to compile the binary
the official changelogs gives us the necessary data:
with this approach, the ynh admin can use cheap machines to host dex (and avoid wasting resources on servers with the ability to compile)
thanks