The OpenSUSE build service currently has RPM packages
The service can automatically build packages for other distributions such as Debian.
@coogor would you consider enabling the Debian build in the service?
With the limited resource of the project, I think it is better for the project to focus only on providing the docker images. And for those who do not like docker, they can also just use python virtual environment.
1 Like
While I share the feeling that we current project resources we can not do more, I always tought there should be a way to automate the package generation for several distros.
A quick search bring me FPM which should be able to produce a distribution package from our python packages without much work.
So if anyone is interested on helping the project package this is a way to explore.
Sure, no problem.
However, while OBS uses the same source for multiple distributions and architectures, it requires a distinct build definition, like a trytond.dsc, to build the Tryton Server. I have not looked into this, but feel free if you would like to try, maybe starting with Show Application:ERP:Tryton:5.0 / trytond - openSUSE Build Service
I agree with @ced here. Not only because of the limited resources but also running Tryton on LTS distributions like RedHat / Ubuntu / CentOS / Rocky Linux etc it is difficult to keep supporting Tryton. Using Docker or a Python Virtual Environment almost removes the need for platform specific packages and I would rather see a kind of script like used with GNUHealth to install and manage Tryton as a server.
On the client side I would look at a Flatpak package which is supported by almost all major distributions.
The most important factor in any discussion like this is to separately document:
a) the developer skills and workflow
b) the client expectations (client includes other developers too)
It is then essential to look at where (a) and (b) overlap.
Example:
a) developers want to produce Docker images
b) clients want to use LTS packages on Debian and CentOS
There is no overlap. If there is no overlap, there are no clients.
I do not expect any volunteer to create packages for free. On the other hand, I suspect there is demand for the packages and I suspect we can all find ways to both obtain funding and include the packaging in the developer workflows.
I opened this topic about OBS/Debian packaging specifically for that possibility, to find out what is possible in that direction but not to create a burden for anybody.
Hi Axel,
I see the last version supported on OpenSuse is 5.0. Did you plan to update to newer series? Did you only support LTS series like the debian project?
Hi Sergi,
I plan to package the 6.0 series for openSUSE, yes. The lifetime of the in-between series (.2/.4/…) is a bit too short for productive ERP purpose, so I do not consider those for packaging.
Package-based installs make sense for LTS distributions, agree (BTW, openSUSE Leap 15.x series is shared with SLE 15.x, which is supported until 2028).
For a container a self-contained, transactional system like MicroOS or Kubic would be an option. Always wanted to test this as ERP backend, but no time yet.
Which script do you mean? gnuhealth-control?
If you run a package based installation (and not vanilla) your dnf/apt/zypper should do most of the job for you…
True. It has its downsides as well, so I personally would still prefer a package…