home Forums # Technical Support Ubuntu Packages

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #941

    Hi Juan,
    I saw your post about creating packages for fuzzylite.

    I can help you create the necessary debian/spec files, but I do think I have the time to maintain the packages in the distributions though…

    I use build.opensuse.org to do the actual building of the packages. Do you have any concern with that?


    Hi Fishwaldo,

    Thanks for your help offer! I would appreciate very much your help creating the necessary files. Do not worry about not having the time to maintain the packages as I could handle the maintenance for every update.

    Opensuse build service sounds fine.

    Let me know how can I help you.



    Hi Juan,
    I’ve got RPM’s building so far. I’ve had to base this off the 4.0 code, as I noticed qtfuzzylite wasn’t building in the current repo.

    You can see the results here https://build.opensuse.org/package/show/home:fishwaldo/FuzzyLite
    (unfortunately the cmake version that comes with CentOS is too old (2.6.4) so I can’t build it there without some “ugly” hacks that I’ll describe later)

    I’ve had to patch the CMakeLists.txt with some updates to make it cleanly install and adhear to packaging guidelines. The patch file is here: https://build.opensuse.org/source/home:fishwaldo/FuzzyLite/fuzzylite.patch?rev=0a9f019455fd2e2000009492c7a40837

    The changes are:
    * Setting the Library Path to “bin” ? Means that the libraries were installed into /usr/bin (but should be into /usr/lib[64]/ (or when we get to Ubuntu builds, into /usr/lib/amd64-*/ directories

    So to handle this, update the library paths to use ${CMAKE_INSTALL_LIBDIR} and included the relevant GNUInstallPaths include in CMakeLists.txt

    * Shared Libraries should use a SONAME, so set the SONAME to ${FL_VERSION}. Its not the best, but probably good enough. CMake will make a soft link from libfuzzylite.so to libfuzzylite.so.4.0.
    This allows several versions of the shared library to exist on a install. So say a user compiled qtfuzzylite against 4.0 and then installed the fuzzylite 5.0 shared library (without updating qtfuzzylite to the latest version), the *old* qtfuzzylite can still find libfuzzylite.so.4.0 as well as libfuzzylite.5.0

    * in qtfuzzylite, set the shared library “hint” to ${CMAKE_SOURCE_DIR}/../fuzzylite/ instead of ${CMAKE_SOURCE_DIR}/fuzzylite/bin/

    I’m not sure how these changes might impact your development work though. At the moment, these changes are automatically patched into the source before building. If you take them into the official repo, then I can drop the patch.

    I still want to add one more change as well – pkgconfig file for fuzzylite – So its easy for other compiling apps to find fuzzylite on the system. This is pretty straight forward. Will incorporate it into the next update.

    Debian/Ubuntu packages will come shortly.

    Let me know your thoughts.

    (btw, you should also consider man pages for fuzzylite and qtfuzzylite – when we package it up, its complaining:
    fuzzylite.x86_64: W: no-manual-page-for-binary fuzzylite
    qtfuzzylite.x86_64: W: no-manual-page-for-binary qtfuzzylite


    Hi Fishwaldo,

    thank you for your progress creating the RPM! I am sorry I will probably not have enough time to check your work this week because I am at a conference with limited access to internet. However, I reply to your comments.

    I am divorcing QtFuzzyLite from fuzzylite to a repository of its own, and I will rewrite the entire application, that is why it does not compile. I have not deleted the sources from the repository because I still need them. You have done great using the sources of QtFuzzyLite 4.0.

    I changed the directory of the output libraries from lib to bin because I found it annoying to have bin and lib, but please make all the changes you find necessary to comply with standards.

    Regarding SONAME, I am not sure having different versions of fuzzylite working simultaneously is a good a idea because fuzzylite is evolving/maturing/changing too fast, and engines created with one version will most likely not build with another version. Furthermore, in recent tests, I have found that QtFuzzyLite 4.0 may start correctly using fuzzylite v5.0, but then crash due to important differences. Therefore, I think allowing multiple versions of fuzzylite might lead to errors hard to find. If you still think there are more advantages in using SONAME, we can definitely give it a shot.

    I like very much the idea of pkgconfig to make it easier to find fuzzylite.

    As for the man pages, it would be great if you could use empty pages to avoid the errors for now. If you have time, please email me a sample format or a link so I can write that as soon as I have some time.

    Thank you very much for your help!

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.