Description of problem: It was some time since Ogre even catched up the ogre-1.7.4 (and not even for current distro but jumping to next f18), it that proccess continues going on, effectively Ogre would never be up to date on latest fedora stable. For instance, if this reports makes 1.8 on f19, who cares until 6 months, when probably it will be again back in time. Personally, 1.8 should have been at least accepted for f18, since the not very major changes policy in same distro is not so mad, but 1.7.4 is only bugfixes or minimal improvements I believe. Still, this packager(s) needs to be more up to date with upstream www.ogre3d.org, and have a little more of motivation, skipping Ogre 1.8 for f18 release is going to be a real dissapointment, lag from day one is very bad. While you (packager(s)) are at it, if you feel like boosting this package consider ogre-ode, ogre-al, ogre-bullet, etc, really good and worth packages from ogre cvs, without no app can do stunning stuff. P.S.: I know Ogre is a little big and slow to build, cause its immense tree. $ bodhi -L ogre f16-updates ogre-1.7.3-3.fc16 f16-updates-candidate ogre-1.7.3-3.fc16 f16-updates-testing ogre-1.7.3-3.fc16 f17-updates-candidate ogre-1.7.3-7.fc17 f17-updates-testing ogre-1.7.3-7.fc17 f17-updates ogre-1.7.3-7.fc17 f18-updates-testing ogre-1.7.4-5.fc18 f18 ogre-1.7.4-5.fc18 f18-updates-candidate ogre-1.7.4-5.fc18 Version-Release number of selected component (if applicable): 1.7.3/1.7.4 How reproducible: Go to ogre3d.org, very often, this package is not up to date. Actual results: 1.7.3/1.7.4 Expected results: 1.7.4/1.8.0/1.8.1 Additional info: Ogre 1.8.1 [Byatis] released! September 2nd, 2012 http://www.ogre3d.org/2012/09/02/ogre-1-8-1-byatis-released
We need to make sure that we don't break existing packages in Fedora by upgrading Ogre. In particular it wasn't clear that the worldforge stuff would be ready for Ogre 1.8 by f18's release. The last I looked, 1.8 support was being done in a side branch that didn't appear to be ready. I would also need to make sure it worked for Vegastrike, but I hadn't heard of any problems there.
I have asked the worldforge guys for the status of ogre 1.8 support. It doesn't look like there is a release yet with ogre 1.8 support, but it may be that it still works without taking advantage of new features. They have also be releasing updates for a few of their libraries and it may be that a new ember release is due soon. vegastrike claims to to work with ogre 1.7+, so it seems likely that that will still work.
I confirmed with worldforge that ember 0.6.3 does not work with ogre 1.8. ember 0.7 is due out soon and will need ogre 1.8.
Thanks for your response. I want to make you note the cegui packaging model: $ yum search cegui cegui.i686 : Free library providing windowing and widgets for graphics APIs / engines cegui-devel.i686 : Development files for cegui cegui-devel-doc.i686 : API documentation for cegui cegui06.i686 : CEGUI library 0.6 for apps which need this specific version cegui06-devel.i686 : Development files for cegui06 cegui06-devel-doc.i686 : API documentation for cegui06 I find this model more than just a convenience, since allows the fedora distribution to follow its philosophy of "bleeding edge" packages, while not forgetting other packages while they catch up. So, if a package would need ogre 1.7, a ogre17 package would be nice to not delay the ogre package itself from upgrading to upstream. Despite the possible causes that may make this model unliked/not well recieved by the packagers, nice to see ogre 1.8 is on the way to be packaged anyway. I note again the ogre-al, ogre-ode, ogre-bullet, even ogre-dotscene (addons) idea. Good work.
I have been experimenting with this at https://bitbucket.org/mpreisler/fedora-ogre18 There is a thread about it on the Ogre forums - http://www.ogre3d.org/forums/viewtopic.php?f=1&t=70794 In the end it didn't end up in Fedora 18 due to me being too busy doing other stuff and upstreams not supporting Ogre 1.8 yet. I would only split the package by "API version" as the last resort. It's much better to convince apps depending on Ogre to upgrade their code. Still busy and not having time for this but I may work on it for F19.
Regarding the addons, these are released separately and are not part of the Ogre source tarball. They should be extra packages that go through separate package review IMO. Making them subpackages of the ogre package is not the way to go. Personally I am not using any of these so I am unlikely to do the work. I am willing to review if someone steps up to package them.
I don't think splitting the API is worth it. There are only a few packages in Fedora that use ogre and they don't usually lag too far behind. I am also not likely to package the add ons unless there is some game being packaged for Fedora that uses them. Other people are welcome to though.
*** Bug 880364 has been marked as a duplicate of this bug. ***
I'm seeing a lot "it's not worth it", "it could be", etc. Now i'm seeing 1.8 on f19? probably?. Mainly cause of packages that relies on it. I'll pick gnome packaging for instance, no matter what it takes out the latest release is on the latest distro release, either it takes full gtk2 interface, which *it does not*, thanks to *version packaging* allowing gtk2 and gtk3 to life together. If they would have follow this policy waiting for all gnome apps to follow gtk3 it would have not meet the fedora policies of releasing uptodate relevant software. This is getting more serious than waiting for 2-4 or 8 games to follow latest api. If they don't/can't care with it, a hold to be popped out of the distro is more acceptable than this nonsense of unrelevant ogre. Right now it would be almost better to not have any ogre available at all. Any programmer will tell anyone that developing for an allready obsolete api is a waste of time, and is not interested. Happens everyday. So please stop considering yourself as a dependency and instead consider yourself as a provider of a technology. *The way to keep all the parts happy is multiversioning*, like it or not, taking effect the faster the better. Else dropping the obsoleted packages. No way older api is usefull to anyone by itself. It just seems a libc.so.5 compat issue. no one cares, just old stuff can't run without it. P.S.: I'm interesting in programming ogre apps, not in any ogre based game actually in fedora, for the record. I wonder how many are in this situation.
Fedora 19 does have Ogre 1.8.1 All the packages depending on Ogre have been modified to support the new API. http://koji.fedoraproject.org/koji/packageinfo?packageID=2678 Pushing it to Fedora 18 would violate packaging guidelines and makes no sense.