The FIFE[1] Engine package in Fedora in the past provided public static and shared objects; From one of my talks with 'prock' from upstream he stated that:
- public shared libraries are not supported by upstream and are not used by any of the current clients; - static blobs are not used by clients and aren't either supported; - all that clients are expecting is the _fife.so in the python-fife package and the respective python stuff;
During the update to 0.3.3r3 made by Tom on request to BZ757352 we supressed the static package... On future updates can we also supress the public shared objects since they are not used by any client and I'm not really sure if anyone will have any usage for them at all... Anyone developing games with FIFE ? :)
Another issue regarding fife is how Fedora currently packages it:
fife: provides currently the dynamic shared objects; fife-python: provides the python wrapped stuff (this is the only package clients expect) fife-devel: development stuff
Would it make more sense to have it this way:
- python-fife (with virtual provides to FIFE, assuming we can Provide/Obsolete a bit for smoother transiction in clients); - fife-libs (the dynamic shared objects, not supported by upstream in any way) - fife-devel
Any comments? Simon? [1] - http://fifengine.de
On Fri, May 11, 2012 at 08:20:47PM +0100, Nelson Marques wrote:
The FIFE[1] Engine package in Fedora in the past provided public static and shared objects; From one of my talks with 'prock' from upstream he stated that:
- public shared libraries are not supported by upstream and are not
used by any of the current clients;
- static blobs are not used by clients and aren't either supported;
- all that clients are expecting is the _fife.so in the python-fife
package and the respective python stuff;
During the update to 0.3.3r3 made by Tom on request to BZ757352 we supressed the static package... On future updates can we also supress the public shared objects since they are not used by any client and I'm not really sure if anyone will have any usage for them at all... Anyone developing games with FIFE ? :)
Sounds like building a library is just an artifact of upstream's build scripts as they are creating their python extension module. Repoquery doesn't show anything in the Fedora 16 repositories that are using the libfife.so.
Another issue regarding fife is how Fedora currently packages it:
fife: provides currently the dynamic shared objects; fife-python: provides the python wrapped stuff (this is the only package clients expect) fife-devel: development stuff
Would it make more sense to have it this way:
- python-fife (with virtual provides to FIFE, assuming we can
Provide/Obsolete a bit for smoother transiction in clients);
- fife-libs (the dynamic shared objects, not supported by upstream in any way)
- fife-devel
If you're going to remove the fife libraries then I'd probably make it look more like this:
* Do a rename package review to rename the package from fife to python-fife. * Have this package only build and ship the python-fife binding. The fife "library" is compiled as part of this as an internal static archive (it's built as a static archive but it's purpose is not to be shipped -- it's just an intermediate container for the building of the python C extension module). * Have the python-fife package Obsolete: fife <= (The version that last shipped a fife library). * Do not have the python-fife package Provide: fife * Do not have a fife or fife-libs package. Do not have a fife-devel.
Just remember that if other packages start using libfife, you'll need to revisit this and probably revert all these changes (so that you're once again building a libfife.so and linking the python extension against that).
-Toshio
2012/5/11 Toshio Kuratomi a.badger@gmail.com:
On Fri, May 11, 2012 at 08:20:47PM +0100, Nelson Marques wrote:
The FIFE[1] Engine package in Fedora in the past provided public static and shared objects; From one of my talks with 'prock' from upstream he stated that:
- public shared libraries are not supported by upstream and are not used by any of the current clients; - static blobs are not used by clients and aren't either supported; - all that clients are expecting is the _fife.so in the python-fife package and the respective python stuff;
During the update to 0.3.3r3 made by Tom on request to BZ757352 we supressed the static package... On future updates can we also supress the public shared objects since they are not used by any client and I'm not really sure if anyone will have any usage for them at all... Anyone developing games with FIFE ? :)
Sounds like building a library is just an artifact of upstream's build scripts as they are creating their python extension module. Repoquery doesn't show anything in the Fedora 16 repositories that are using the libfife.so.
Another issue regarding fife is how Fedora currently packages it:
fife: provides currently the dynamic shared objects; fife-python: provides the python wrapped stuff (this is the only package clients expect) fife-devel: development stuff
Would it make more sense to have it this way:
- python-fife (with virtual provides to FIFE, assuming we can Provide/Obsolete a bit for smoother transiction in clients); - fife-libs (the dynamic shared objects, not supported by upstream in any way) - fife-devel
If you're going to remove the fife libraries then I'd probably make it look more like this:
- Do a rename package review to rename the package from fife to python-fife.
- Have this package only build and ship the python-fife binding. The fife
"library" is compiled as part of this as an internal static archive (it's built as a static archive but it's purpose is not to be shipped -- it's just an intermediate container for the building of the python C extension module).
- Have the python-fife package Obsolete: fife <= (The version that last
shipped a fife library).
- Do not have the python-fife package Provide: fife
- Do not have a fife or fife-libs package. Do not have a fife-devel.
Just remember that if other packages start using libfife, you'll need to revisit this and probably revert all these changes (so that you're once again building a libfife.so and linking the python extension against that).
Toshio,
Thanks for your suggestions; the call isnt actually mine, but Simon's (if it was me I would enforce it). Instead of just nagging Simon to do it, I'll try to prepare things up so I can bring it to his attention.
From my talk with prock, there are no plans __currently__ to change
the situation with the libs, but can change in the future; if such happens we need to answer by reinstating the libs once more. Also upstream default build/install targets don't install libs, just the python/swig wrapped up stuff, which is what the clients expect.
I'm going to work a bit on this and propose to Simon, and will include your suggestions as they seem quite racional to me. I would also like to see if this package gets officially supported by upstream and up to point how we can collaborate to provide a good implementation of FIFE in Fedora.
Thanks.
NM
-Toshio
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- Nelson Marques // I've stopped trying to understand sandwiches with a third piece of bread in the middle...