On Wed, Aug 13, 2014 at 3:20 PM, Kelsie Flynn <kelsiegflynn@gmail.com> wrote:
[SNIP]

Richard,

While what you said is not "incorrect". I want to add some things. My opinions are directed towards RPMfusion and all members with decision making power
for building packages, not just you.

Thanks for casting a wide net and including me...

 

 My uncle Doodle used to say:

 "Opinions are like *ss#holes, Everybody has one!".

Like it or not.
I don't come out from behind my rock too much.
But when I do, I have some things to say and this is my opinion!

>That's currently not possible because the version of QT in RHEL is too old and the version in EPEL (QT5) is too new.

*Don't use qt5 with EL6. It's not binary compatible directly with el6's qt4-6.2 but qt4-4.8.X is. Someone told you wrong to try it.

No one suggested I try it, it was just a statement. Both versions are available and neither work.
 
*Use this repo instead. Created by SIC from Fedora # This was built isolated in /opt, I have rebuilt it against 4.8.5 with Axels' reference system for qt47.


https://repos.fedorapeople.org/repos/sic/qt48/epel-qt48.repo
 
You have to force it(unless you rebuilt it) because mythtv packages from Axel and RPMf are built against the qt*-* and not qt48-qt-*.

My qt48-4.8.5 spec/build that I upgraded from (sics) previous great work on this subject will be turned over to Axel with a matter of days. And then it will

If someone wants to develop a parallel installable package that's compliant with the guidelines (i.e., not installing into /opt) then I would welcome it. I don't personally have the time to do that with what little time I'm left with after work and home life.
 
Back on point:

>Since RPM Fusion has a policy not to replace currently shipping packages we're at an impasse!



RPMfusion already has other qt4's in the RPMfusion repo Richard. As you know, they just don't work(very well), even though they sit there...like they might.
Fact is:
Axels 4.7 worked. Up to the change upstream in mythtv.

What qt'4 are you talking about? RPM Fusion AFAIK does not provide ANY qt4 packages, 4.6 is in RHEL and 5 is in Fedora EPEL...
 
>Since RPM Fusion has a policy not to replace currently shipping packages we're at an impasse.

I'm sorry again Richard. ....
No direct disrespect intended as I like you and all the peps at RPMfusion and Axels group. Even though I only know you by reading posts/notes from your work!

Indirect disrespect then? I understand your point of view on the policy and I'm frustrated by it a bit as well, bug I only maintain the package at RPM Fusion. I have no leadership position there whatsoever.
 
In all fairness,   

This is by choice or technical decision based solely on the decision making processes' of the past and is now technically a MOOT point.

I don't think it was ever a technical issue to begin with but a policy choice, and I don't see RPM Fusion shipping packages that install into /opt anytime soon.
 
I'm not religious, but here's My philosophy, Regarding the ongoing pissing contest between RPMf and ATrpms.

Is it ongoing? The result may be unfortunate but I think it's pretty well settled. Personally, I have learned some of the history but I was not a packager (for Fedora or RPM Fusion) at the time it happened.

Ok, snipping the rest of the message as it's not technically relevant to this thread. If you want to have a philosophical discussion about the history of ATrpms and RPM Fusion and your problems with RPM Fusions policies, feel free to do so, but please don't hijack this thread to do it.

Thanks,
Richard