It is only used in LandscapeMgr to import compressed landscapes. I found some QTBUGs on this, discussion is going for 4 years now.
I think (2) seems best, just rename the files and class, and activate inclusion on Windows in the CMakeFile. This should keep compilability on all platforms. Other opinions? Kind regards, Georg On Mo, 25.05.2015, 07:11, Alexander Wolf wrote: > I think this message is important for us. Any ideas? > > ---------- Forwarded message ---------- > From: Sune Vuorela <s...@debian.org> > Date: 2015-05-25 0:46 GMT+06:00 > Subject: [Debian-astro-maintainers] Bug#786715: stellarium: Uses private > copies of external headers > To: Debian Bug Tracking System <sub...@bugs.debian.org> > > > Source: stellarium > Version: 0.13.3-1 > Severity: serious > > Dear Maintainer, > > Stellarium has a copy of qzipreader/writer header files taken out of Qt, > and uses the internal, but unfortuantely available, symbols out of Qt > Gui. It can be directly seen due to the dependency on the internal qt > versioning as in qtbase-abi-5-3-2 which is generally a sign of doing > something dirty, and will require a rebuild on each new Qt upload. > > If the QZipReader/writer classes changes (they can do that, they are an > internal thing to Qt), stellarium will not work or maybe even crash > randomly. > > I'd suggest one of the following solutions: > > 1) Use an actual public zipping library. KArchive and quazip are two > currently available in Debian > > 2) Copy out the relevant bits from Qt *and rename* them (like add a > namespace or something). (The current qzip.cpp found in the external > directory could be used, but needs to actually be built. Hint: ! is not > a valid negation operator in cmake) > > 3) much discouraged, but still better than status quo. Use the privately > exposed headers in qtbase5-private-dev of qzipreader_p.h and > qzipwriter_p.h to at least ensure that things are in sync. This also > requires changes to the build system. > > 4) convince Qt upstream to make QZip* public api. That's likely not > going to happen, and even if it was, we would need a interrim solution. > > Getting something going soon would be nice to detangle stellarium from > the next qt upload. And 3) doesn't solve that. > > I do somewhere have a quick and dirty patch for 2), but I really think > you should consider 1). > > /Sune > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > _______________________________________________ > Debian-astro-maintainers mailing list > debian-astro-maintain...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/debian-astro-maintainers > > > > -- > With best regards, Alexander > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
