Getting Urho3D into Debian

Hi guys,

Currently I am in the process of figuring out how to create a .deb package of Urho3D. My goal is to get Urho3D into Debian. Then, on many Linux distributions (there are over 120! distributions that are based on Debian) installing Urho3D will become as easy as:

The creation of a .deb package is not an easy task, and it’s best to automate it. I was looking at sourceforge.net/projects/urho3d/files/Urho3D/ and noticed that there are *.deb packages available for download. Are there any scripts already available to generate a .deb package from Urho3D source?

Some other questions:

[ul]
[li]The future Debian package should be built as a shared or as a static library?[/li]
[li]The future Debian package should be named “urho3d” or “liburho3d”?[/li]
[li]Maybe there is already an effort underway to get Urho3D into Debian?[/li]
[li]Maybe it’s a good idea to create a separate GitHub repository under github.com/urho3D to store all of the package building scripts?[/li]
[li]What about RPM packages and Red Hat based distributions?[/li][/ul]

You can use fpm for quick and dirty .deb/.rpm packages, but they will never be accepted by Debian and Fedora (due to their low quality and lack of metadata, among other issues).

This page might have some information on Debian packaging as well.

We don’t have manually crafted package spec file for Urho3D yet. All spec files are auto generated by CMake. As it is, it already can produce Linux packages for deb and rpm. It even already has the /usr/lib vs /usr/lib64 taken care of for 64-bit packages. Having said that, as it is now, I reckon they are nowhere near to be accepted. Not that I have tried though. There are a few reasons for that. One of them is that our packaging approach is monolitic instead one package for source, one for lib, one for doc, one for samples, and may be one more for static lib (they like shared lib by default). I also think the way Urho3D embeds those third-party libs might be an issue to them. I am not saying what we have done is wrong though. Whenever there is a bug in the 3rd-party lib or there is a Urho3D-specific need for local adaptation then it is faster to do all that in our own copy of those 3rd-party libraries rather than submitting the changes up and then wait for upstream to decide and respond. This approach is fine when Urho3D lib is just a localized library used by some game apps. But I think it is a fat chance to have it becomes a first class citizen as one of the system-wide libraries this way. This is my personal opinion from my experience with Fedora distro.

Technical aside, There is also issue with man power to back port bug fixes from master branch to existing release branches. At the moment we all know Urho3D devs don’t do that at all. And I don’t think that is acceptable on any Linux distros, especially Debian one. Or to put it in another words, whoever the person becomes the Linux package maintainer for Urho3D then that person must assume the back porter role. My two cents again.

What do you mean by master branch and existing release branches? Are you talking only about the Urho3D GitHub branches? So that if something gets fixed in master, it doesn’t get back ported to, say, version 1.4 of Urho3D?

Yes. The fact that one can only find 1.4, 1.5, etc as a git tag and not as a git branch in our git repo already shows that we don’t do back port.

OK. So I am thinking to automate the process of creating a modular Urho3D out of the main source tree. I am writing a script to create the following projects:

[ul]
[li]liburho3d-core - a shared build of Urho3D without samples, without data, and without docs[/li]
[li]liburho3d-data - just the Data/* and CoreData/* folders[/li]
[li]liburho3d-doc - documentation[/li]
[li]liburho3d-samples - the binaries of all the Urho3D samples[/li][/ul]

In the distribution’s repository there will also be a meta package liburho3d which will pull in all of the above if the user requires it.

Also, there will be a liburho3d-dev which will contain all of the sources.

weitjong - did I miss anything?

Regarding back ports. There is a separation between Debian sources (the source code from which Debian packages actually get built) and Upstream (the Urho3D official GitHub repository). I will be taking care that any fixes that are made to Debian Urho3D sources, actually end-up knocking on the door of the Urho3D official GitHub repository = ) So when a new release of Urho3D happens, some (if not all) of the fixes from Debian are in it. This will make it easier to just take the new release, and proceed to incorporate into Debian as a new version of Urho3D.

As I said, I have not done any of these before. I am not a Linux package maintainer myself. People always take for granted a good package maintainer, nobody will give credit or say thanks when the package just work. It should work like all the other thousands of packages. But when the package gone bad then immediately people will know that it is your package. Even when the package is actually fine and it does not work simply because of PEBCAK symptom, the maintainer would still receive the blame. Believe me as I have seen that quite frequently, especially from those newbie Linux users. If this still hasn’t scared you off then please proceed. BTW, I think you have confused between dev package and source package.

Yes, you are right! liburho3d-core is actually liburho3d-dev. And *all sources (basically the entire Urho3D source tree) should probably go to liburho3d-src.

Great idea. This could be something like Ogre’s Debian/Ubuntu distro, ogre3d.org/tikiwiki/Installi … sion=Linux

One thing to note is that Urho build is customizable and a game might want to leave out certain subsystems or otherwise tailor the build. A packaged build would probably have all CMake build options set to default. For the most part this is OK, but at least one build flag where I don’t think there’s a “right” answer is URHO3D_SAFE_LUA, where you choose either better crash safety, or performance.