Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

On Tue, Jul 16, 2019 at 1:41 PM Peter Maydell <address@hidden> wrote:
>
> On Tue, 16 Jul 2019 at 12:17, Aleksandar Markovic
> <address@hidden> wrote:
> >
> > Hello, Gerd, Daniel, and others involved.
> >
> > I have multiple reports from end users that say that transition from
> > SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> > In that light, they don't appreciate removing SDL 1.2 support from
> > QEMU. The most notable example is Ubutnu 16.04, where it looks there
> > is no way of installing SDL 2.0 that does not involve complete OS
> > upgrade, which, for various reasons, many are not willing to do.
>
> One of my build test machines is an Ubuntu 16.04 system
> (specifically 16.04.6 LTS), and it has SDL2 installed
> and the built test includes compiling the SDL2 UI. So I'm
> not sure what's happening with your end users -- do you have
> more detail on what their setup is and what isn't working for them ?
>

I gather that their systems are one of earlier versions of Ubuntu 16.04
that has SDL 1.2, and not SDL 2.

Let me explain the situation in more details. The build and test beds in
many organization are often maintained in a state that is not subject to
change over time. This means no updates/upgrades, except some
really rare exceptions. The rationale is that build and test beds should
be "constant" in time to achieve reproducible build runs and test
executions. In some organizations such setup is frequently achieved
by using virtual machines that automatically revert to their initial state
on each reboot.

But I digress. Let me quote our Linux deprecation policy for reference
for future readers here:

"For distributions with frequent, short-lifetime releases, the project will
aim to support all versions that are not end of life by their respective
vendors. For the purposes of identifying supported software versions,
the project will look at Fedora, Ubuntu, and openSUSE distros. Other
short-lifetime distros will be assumed to ship similar software versions.

For distributions with long-lifetime releases, the project will aim to
support the most recent major version at all times. Support for the
previous major version will be dropped 2 years after the new major
version is released. For the purposes of identifying supported software
versions, the project will look at RHEL, Debian, Ubuntu LTS, and
SLES distros. Other long-lifetime distros will be assumed to ship
similar software versions."

However, any distribution is a "living creature". Packages are constantly
added and modified, and Ubuntu 16.04 looks different at its inception
and now, even though it bears the same version number, 16.04.

The problem here (not directly visible from the policy) is that it looks
as if we implicitly assume that any end user is constantly updating and
upgrading their systems - and that may not be true. I think we can't say
to such user: "Why didn't you update your Ubuntu 16.04?" It is up to the
user how he/she wants to use their OS, we can't and shouldn't dictate
that - at least this is my understanding of our desired relations to the
end users.

> > It looks to me that depreciation of SDL 1.2 was a little premature. My
> > humble opinion is that we should not look at release dates of
> > libraries when we deprecate them, but release dates and end-of-support
> > dates of major Linux distribution that include them.
>
> That is indeed the way our deprecation policy is supposed to
> work -- we care about the versions of libraries that distros
> have shipped in their LTS, not what the upstream library
> release schedule is.
>

I think there seems to be a hidden unclarity in our deprecation policy,
related to the situation I described above.

I appreciate your response very much!

Yours,
Aleksandar

> thanks
> -- PMM