Is it that hard to maintain a script which triggers once you post a milestone? This updates distributions of your app (windows exe; android apk (including posting it on the play store); linux snap, flatpak, and deb; and a web version) and posts said updates on your website. Is it that hard?
1 Like
There is a lot of work behind that phrase. Maintaining multiple versions of an app for various systems is not something I would enjoy.
Once you have all the versions, running an update script should be trivial.
I dont get what you are complaining about … that is what mostly happens?
1 Like
Yes, there is indeed some work required to pull up such a CI system. But afterward you (mostly) can lean back, enjoying seeing computers working for you.
2 Likes
So you think @xahodo meant a script for one user doing updates… I thought meant a developer updating multiple versions .
I am getting a reputation for misunderstsnding people’s posts. Must be old age. I hope it is not progressive.
1 Like
Same here. One dev builds and deploys his app for different platforms.
1 Like
OK, that means I misunderstood your reply … I thought you were talking about one user doing updates. ?
No escaping old age.
1 Like
For me, it reads as he has developed an app for multiple platforms and now wants to automate the build and distribution process.
2 Likes
What I wanted to ask is whether it’s so difficult to create an update script for a software developer in order to distribute his application for various platforms?
ARGH! Here not being a native English speaker really hurts. I hope I didn’t repeat the same flunk I posted earlier.
2 Likes
No problem, you’re not alone.
Short answer: Yes, it’s difficult, or at least not trivial.
1 Like
We understand. In this case I think I caused the confusion.
OK , you meant the developer scenario.
They do use build scripts.
I think what you are asking is…
“Is the difficulty of making multiple ports to different distros sufficient argument to justify flatpaks and snaps and appimages?”
I think not.
but
that is not the main reason for containerizing software.
There is also the issue of dependency hell.
Dependency hell could be dealt with in other ways, for example package systems dealing properly with multiple versions of libraries.
1 Like
I was using such pipelines for many of my projects. Besides the fun, you don’t forget anything. 
1 Like
It would seem to me as a non-programmer that this is something that could become a standard application program if someone was to write one… Obviously it would take a good bit of configuration, and downloading the appropriate tools to generate each package type. but it would seem to me that the same tasks would need to be done to produce packages no matter what the program being packaged was…
ex-Gooserider
1 Like
You are right. Most developers use build scripts to setup packages for a specific destination.
For example Void linux supplies package build scripts for public use. They are described here
You can see from that it is a complicated topic. Developers complain that it is too much work, so they tend to favour universal packaging methods like flatpak.
1 Like
I agree it seems to be a constant complaint, but it would seem like there should be a way to design an application that automates the process… Get the source and related files to the point where you can make (for example) a .deb package file, and then have a ‘repackager’ program that takes the .deb and turns it into the various other package types…
Doesn’t have to be a .deb as the start package, just whatever the app designer wanted to make the default starting point…
ex-Gooserider
1 Like
Indeed, Void linux has a program that converts .deb files to .xbps files. …Other non- debian distros should provide the same.
I agree with you 100% …It is a simple matter of programming.
It may need updating at times , because distros evolve.
1 Like