[suggest] Re: suggest Digest, Vol 60, Issue 13
nkadel at gmail.com
Mon Jun 14 14:07:06 CEST 2010
> Date: Mon, 14 Jun 2010 11:45:13 +0200
> From: "Yury V. Zaytsev" <yury at shurup.com>
> Subject: Re: QRe: [suggest] please update libdvbpsi
> To: arnebjarne72 at hotmail.com
> Cc: suggest at lists.rpmforge.net
> Message-ID: <1276508713.7686.35.camel at mypride>
> Content-Type: text/plain
> On Sat, 2010-06-12 at 22:01 +0200, arnebjarne72 at hotmail.com wrote:
>> I can compile VLC without the Qt4 GUI, making cvlc work.
> The reason is very simple: the developers migrate to newer distributions
> that ship newer Qt that comes with new features and bug fixes. The
> interface resource files format is not backwards compatible, so it's a
> constant pain to make sure that things still work on older
> No developers use RHEL 5 anymore, so they just don't care whether it
> still works there or not.
But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.
In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?
>> I started changing and backporting the failing QT4 code, but stopped
>> again. I guess the code was changed for a reason and I have no clue
>> what impact changing the code from Qt 4.4.0 back to Qt 4.2.1 code
>> (from vlc 0.9.8).
> This is something I did for SMPlayer when I was still using CentOS for
> multimedia and wanted a decent recent mplayer front-end. It's a heroic
> effort and you need some expertise.
> If you want to go this route I'd rather had a look at 0.9.9a instead.
> I think the most practical solution would be in fact to come up with
> static builds of VLC against latest Qt.
Ouch. That's generally something to avoid. It's done for a few small
components of Subversion, like SQLite, to avoid that kind of system
> Then, we would be able to switch all the packages that require newer Qt
> to buildrequire this package and statically link against its libraries,
> which will be kind of Qt backporting framework.
That's a big indeavor, providing all the system components in newer
versions. I've seen people try that stunt, but it usually breaks down
pretty fast because they wind up failing ot update speficic
One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".
> However, I don't have time and energy do mess with it. I don't need it
> anymore for myself and I'm not gonna get paid for it.
> If you want to have a go at it I wish you best of luck... :-)
Agreed, it's a lot of work.
More information about the users