Do we really want to get into the Debian archive?

[paddatrapper]

There was a long discussion on Debian Devel around how to package large complex applications like LibreTime for Debian. Currently the issue is that Debian packaging policies are difficult to adhere with and an update to any one dependency could break the entire app. For example, GitLab took a year to package and is very brittle, which makes supporting it for the duration of Stretch difficult. Even Salsa (the Debian GitLab instance) does not run this package, rather manually using upstream's install and upgrade methods.

Perhaps we need to look at a 3rd party deb as our packaging method (so host a Debian archive that users can add to apt and install from) or package as a snap/flatpack and distribute that through the repos provided by either project.

The custom archive approach is appealing as we already have the basis for it. We could just roll back some of the library packing commits here and it should just require some tweaking before it is usable. Obviously we would have to include some other packages such as the Zend 1 framework which is only available in unstable currently. The disadvantage is that we would need to maintain a custom apt archive.

A containerised snap (or flatpack I guess, though I am less familiar with flatpack) can be uploaded to the snap store where users can easily download it. It is automatically updated and can be automatically built from GitHub releases. The issue with this approach is that we would have to start from scratch and learn how to create a snap (apparently just a yaml file).

[Robbt]

This seems like a better idea than getting the project as a whole added as a package into Debian at this point.

[AViSource]

Hi. I just discovered LibreTime. I have been using Airtime.pro for over a year but just signed up for a hosting account using Ubuntu 16.04 Server 64 bit. I have root access and can use SSH Console to do installs. is there an install script that I can run to install LibreTime on the server?

[paddatrapper]

@AViSource, yes there is. The source is here and docs can be found on the website around how to install it. Many of the other docs are out of date or refer to airtime, but they should be a good starting point either way. The install script should wok fine on Ubuntu 16.04, but if you run into issues, you can discuss them on the forum

[hairmare]

@paddatrapper It took me a bit to get through the meat of the Debian bug you posted. The issues raised do seem to have a lot of relevance. In the long run it would be very sexy to be a real part of Debian, as it opens LibreTime up a very wide user base but overcoming the type of packaging hurdles Gitlab had to overcome probably won't be sustainable for us. I think even taking care of liquidsoap will probably be quite some work already and offer LibreTime more than enough value during a typical install.

I've been hosting CentOS packages on OBS and have been thinking about moving them to a dedicated libretime OBS "home:" project. OBS also builds Debian packages and I could help set up automated integration with this repo so we can manage the control files here and let OBS handle building and hosting.

Travis already builds an enriched tarball that contains all the needed php components (including Zend Framework 1) so you can just dump it into the PHP include path and you get one large monster package that contains everything. We might even consider packaging to /opt for Debian, I'm not sure what the sane thing to do is there. AFAIK we can mostly live with the compiled python packages already provided by Debian that we require and there aren't that much missing that upstreaming them is impossible. If we start moving JS parts to bower or npm I plan on adding that to the enriched tarball from travis as well.

Apart from snaps and flatpak there is also AppImage and Juju Charms that are similar. When it comes to containerization technology I've been putting my focus on Kubernetes and Docker but the underlying technology of all of these stacks is rather similar. I haven't found any real blockers so far but haven't found the time to put much focus on the effort since my production deploy is based off of my RPMs and runs on a load of VMs. Personally I would probably go for Flatpak or even just recommend using docker and some kind of orchestration when it comes to containerization.

What I see as the main challenge on how to offer an official containerized installation is that we need to integrate with the ecosystem in a way that everything just works when it comes down to integrating 3rd party services that already exist in the ecosystem (ie. rabbitmq and postgresql). At least on Debian a managed install of these components already exists to some degree.

[paddatrapper]

Sorry, yeah it is a rather long thread. I would also really love for LibreTime to be in Debian main, but maybe we should do something like OBS or containerisation until the new "vdeb" format is finalised. For a third party deb, /opt/ is probably a good place and complies with the Filesystem Hierarchy Standard

On the python side we have pretty much everything in main already (and we can just depend on them), JS and PHP libraries we can bundle. I'll need help when we get there around how to integrate the libraries with PHP and LibreTime.

At least for snaps, there is dependency management, but it requires the dependencies to be Debian packages or snaps, but I think a all-in-one deb is probably easiest. I shall take a look at building at least a stand-alone deb for the meantime that can then be integrated into OBS. I've never worked with OBS before, so I don't know how that side of things works.

[narcisgarcia]

It's easier to implement a self-managed APT repository, same as PPA for Ubuntus.
Containerization of builds makes software more difficult to integrate and tune for administrators.
I prefer a more consistent packaging with OS packages design.

...and to be allowed to do only this for upgrades: apt upgrade

[jooola]

Some reference to some of my comments from another ticket.

libretime/libretime#1207 (comment)

libretime/libretime#1207 (comment)