Handling different versions of liquidsoap

[jooola]

Is your feature request related to a problem?

1. To develop the liquidsoap scripts, in particular to work on the future versions of liquidsoap, we need to find a way to install a specific version of liquidsoap inside the containers. We also want to test the changes we make with the version of liquidsoap.

2. We may want to run with a specific version of liquidsoap to have a specific feature not present in older versions.

3. We have been supporting multiple versions of liquidsoap, which can cause some headache to maintain (I think supporting the 1.4 + 2.0 + 2.1 combo will be funny to do). We might want to only support a single version of liquidsoap. That said, I am unsure about this idea, relying on the distributions package has been our way of doing, but supporting multiple versions might become difficult. Is there a way to have the best of both worlds ?

Describe the solution you'd like

1. Passing a custom .deb package that we downloaded from the liquidsoap release page https://github.com/savonet/liquidsoap/releases via a build argument is easy enough for our dev builds. For testing, we might need to prebuild some dev variants with different versions of liquidsoap.

2. If users want to run libretime with a specific version of liquidsoap, we might want to provide variants for the container images that include liquidsoap (analyzer and playout), and we could have for example libretime/libretime-playout:3.0.2-liquidsoap-2.0 which include liquidsoap 2.0.x

3. I don't know how to have the best of both worlds. I wonder how much benefit we gain from sticking to the distro versions of liquidsoap, the bulletproofing that usually happens on distributions packages might not necessarily make sens in the context of the liquidsoap package. That is if we trust the liquidsoap release page .deb files.

Describe alternatives you've considered

No response

Additional context

No response

[paddatrapper]

I would strongly prefer to match distro liquidsoap versions. Fixing a specific version doesn't mean that we can avoid supporting liquidsoap v2, it just delays it and prevents us from getting important fixes too. At least when we match distro versions, we have a known support window and can plan around it

[jooola]

This means we have to support multiple scripts for liquidsoap. I know that liquidsoap 2.0 has a %ifversion statement, that can preprocess the script based on the version we run, so maybe we don't need a really complex jinja templating setup for the libraries, but we still have to support 1.4 as our main and recommended version for now (until we iron out the liquidsoap 2.0 scripts).

So we might need to duplicate the libraries files until we only support >=2.0 versions. I'll check if using a some jinja can help us with that, until we only use %ifversion.

[jooola]

I wonder how easy is it back port fixes into the packaged version of liquidsoap ? @paddatrapper

There are a bunch of bug fixes provided in the 2.0.x series as well as in the 2.1.x series, but the packages cannot upgrade to the next patch version, as per the Debian policy (if I understand it correctly) and because some bug fixes release on the liquidsoap side also include breaking changes.

I don't have any case yet, but according to the changelog of both liquidsoap series, there are a bunch of fixes that could be back ported as patches into the packages.

This is one reason why I came up with this ticket, I personally run with the latest patch version supported by libretime in production.

What is the policy for pushing packges to debian backports ? Could this be a solution for us ?

[paddatrapper]

In general, only RC bugs are backported to stable. You can't update to a new patch release, but you can take a targeted patch file and apply it to stable, assuming it is required to fix some use-case. For example, there are some changes that the liquidsoap requested in #1033068 that I backported to the version that will be in Bullseye.

Backports is definitely an option. Any package that has migrated to staging can be backported to stable or oldstable. The biggest issue with doing that with liquidsoap is that liquidsoap has a bunch of dependencies that Savonet modify in lockstep with liquidsoap. So backporting liquidsoap can requires backporting up to 17 packages and I just don't have the time to do that.

[mp3butcher]

i've began port libretime for ubuntu 22.04 (and so liquidsoap2.0)
it curently run but i still have issues...(callbacks,crossfade,ssl..)
is there any related public work on it? (a git branch i missed for ex)

[jooola]

@mp3butcher This is great, I had a branch locally, but I didn't go really far, so I don't think there is some work that has already been done.

[mp3butcher]

@jooola can a branch could be opened for my work?
I think It might be wiser
I still have recurring annoying errors:
libretime-liquidsoap[471344]: [tcp @ 0x7f97a4011ec0] Failed to resolve hostname dummy: Temporary failure in name resolution
and also
an error concerning undetermined version of liquidsoap
I don't know how to fix it

[jooola]

can a branch could be opened for my work?

Not sure to understand your request, isn't your PR good enough ?

I still have recurring annoying errors:
libretime-liquidsoap[471344]: [tcp @ 0x7f97a4011ec0] Failed to resolve hostname dummy: Temporary failure in name resolution
and also
an error concerning undetermined version of liquidsoap
I don't know how to fix it

Let's keep the discussion in the PR, or on the Matrix channel.