Re: Stellarium 0.12.4 legacy
* Tomasz Buchert [2014-08-11 11:24:28 +0200]:
> On 11/08/14 10:58, Оlе Ѕtrеісhеr wrote:
> > Tomasz Buchert <tomasz.buchert@inria.fr> writes:
> > > one of the stellarium developers asked me if we could create
> > > a legacy version of stellarium 0.12.4 (the current version
> > > that is likely to be in jessie is 0.13.0 [1]).
Why (only) 0.12.4? In perusing the archive of the stellarium-pubdevel
mailing list I came upon a comment by Alexander on 2014-07-20 mentioning
0.11.4 as the last version that was expected to work on a certain piece
of legacy hardware (Radeon IGP 320M, OpenGL 1.3 only). It seems that this
dropping support for older hardware is a recurrent event in Stellarium
development. Where does one draw the line of what should be in Debian
(as opposed to externally maintained packages)?
> > What is the status of the 0.12.4 development? Will they fix bugs in this
> > release or just ask to update to the 0.13 line? Since it was an upstream
> > developer who came out of this idea, he can probably do some statement
> > how they handle the 0.12 line themself.
>
> 0.12.4 is End-Of-Line, but I've just asked them if they are going to support
> 0.12.4 in the future. Note that stellarium has low number of bugs and it
> shouldn't be a big problem.
Security holes are the only ones I'd really worry about. Does Stellarium
have a lot of interactions with the network? (Lookups in online catalogs,
etc.) Is that part of the code stable enough for trivial cherry-picking?
> > > The reasons he mentions:
> > > * 0.13.0 requires OpenGL 2.1+ and shaders - this maybe
> > > problematic for machines older than 5-6 years or some Intel GPUs;
> >
> > I am not really familiar with opengl; can you make an example what is
> > not supported (under Debian Linux)?
>
> As far as I understand, it's about hardware support. Older GPUs are unable to run
> stellarium 0.13.0, because they don't implement necessary features.
Wouldn't it be more accurate to say that Stellarium can run, but only very
slowly because hardware acceleration of OpenGL API calls cannot be used?
> > > this version runs on Qt5 as well
> > > * on the other side, 0.12.4 requires only OpenGL 1.4 without shaders;
> > > this version runs on Qt4
> >
> > Why is qt5 vs. qt4 an issue?
>
> Qt is not an issue as far as I can tell (and probably it shouldn't be mentioned :) ).
A comment by Georg Zotti (ibidem, 2014-07-19) says that "it was a terrible
struggle to get over the QT5 barrier, and the struggle is not over IMHO".
So maybe there are enough rough edges in 0.13.0 to make people want to
stick with 0.12.4 until 0.13.1 is out? (Is the jessie freeze date poorly
aligned with Stellarium's release schedule?)
> It seems that Qt5 requires only OpenGL 1.3
> (http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL), but if Alexander could
> confirm this for me...
That's not my reading of that page. The Qt OpenGL module requires OpenGL 1.3
but is now deprecated in favor of the Qt GUI module (see the warning in
http://qt-project.org/doc/qt-5/qtopengl-index.html) which has stricter
requirements. The question is whether Stellarium has started that transition.
> > > I'm looking for a healthy discussion if we want such a package in jessie,
See my points above. Maybe in jessie but no further?
> > If even upstream sees the need to support older opengl versions: maybe
> > they could do so in their current development? Maybe as a configuration
> > option? Then, there would be only one code base, and the -legacy package
> > would not be decoupled from the main development branch.
>
> Alexander should comment on this, but I'll put forward my point of view.
> As mentioned, 0.12.4 is EOL, they are not going to develop it anymore.
> s-legacy would be there only to provide stellarium for older machines
> that will be unable to run newer versions. It would never ever advance
> its version.
> It would be great if 0.13.0 could support older hardware and we would
> have one stellarium package in the archive. I have no idea what development
> effort it would require, but since stellarium-legacy was proposed, I guess
> it may be unfeasible.
In the long run they may have no choice but to migrate away from deprecated
Qt features. The only question would be one of timing.
> There is another solution, which I don't quite like, but must mention:
> we could ship 0.12.4 instead of 0.13.0 with jessie for the purpose of
> keeping support for older machines.
Does 0.13.0 have RC bugs? If not, it seems silly to deprive those users
who *can* run it of the option to do so and enjoy the new features.
Reply to: