2012/5/11 Toshio Kuratomi <a.badger@xxxxxxxxx>: > 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@xxxxxxxxxxxxxxxxxxxxxxx > 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... -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
