Deb Files

[Luiji]

Many package managers have frozen CEGUI 1.6.x, and a game that I play from http://secretmaryo.org/ requires CEGUI 1.7.x. Many users of this game have had problems because they don't have experience building the libraries, so it would be nice to either have either binary .TAR.GZs with installation scripts or .RPMs and .DEBs with binaries.

If you want, I could try my hand at building a .DEB file, though I haven't done so before. .RPMs I once tried, but they seem a lot harder.

P.S. I like the smiley.

[CrazyEddie]

Hi,

I am not opposed to the idea. I'm happy for you to have a try at this for us, since I'm mainly engaged in other areas at the moment. Though I might be persuaded to have a stab at RPMs some time, then if you have done the DEBs we can either issue both or see which is the most popular or what have you.

All hail the smiley:

CE.

[Luiji]

I'll take a crack at Debian package creation. RPM and Deb files are usually not a one or the other deal, as they are like a Deb package and a MSI installer, two different mediums for two different operating systems. Deb files are only used on Debian-based systems from what I gather, and RPMs are used as a standard amongst most other Linuxes, including openSUSE. It is hard to say that one is better then the other. Although it is possible to port RPMs as Deb files, it doesn't always produce a usable file, which is why I personally believe that both should be maintained.

*cracking fingers*
*starting debfile creation*

[Luiji]

I noticed that files cannot be uploaded on this forum. How am I to upload the Debfile?

[CrazyEddie]

Hi,

You could either email it to me or upload it to some free hosting and I'll add it to sf.net. Once I've check it over I might well make you an offer you should probably refuse

CE.

[CrazyEddie]

To update on this, I spent some time yesterday playing around with our old obsolete rpm spec file, and ultimately ended up creating a totally new one from scratch. I've not committed this back to subversion yet because there is still some minor things to address (and decide upon). The end result of this will be a .spec file that anybody will then be able to use in order to create a set of RPM packages. I've gone for a set of packages because this way we can support various CEGUI options without burdening the main CEGUI package by pulling in lots of unnecessary dependency packages.

Basically the .spec file that we will now support will produce the following 15(!) packages:

• CEGUI: Contains the main shared libraries configured with Expat and SILLY as default loadable modules. Basically contains: CEGUIBase, CEGUIFalagardWRBase, CEGUIExpatParser and CEGUISILLYImageCodec.
• CEGUI-devel: Contains the headers and libs required for development.
• CEGUI-opengl: Contains the CEGUIOpenGLRenderer shared library.
• CEGUI-opengl-devel: Contains the development lib for the above.
• CEGUI-ogre: Contains the CEGUIOgreRenderer shared library.
• CEGUI-ogre-devel: Contains the development lib for the above.
• CEGUI-irrlicht: Contains the CEGUIIrrlichtRenderer shared library.
• CEGUI-irrlicht-devel: Contains the development lib for the above.
• CEGUI-lua: Contains the Lua script module shared library.
• CEGUI-lua-devel: Contains the development lib for the above.
• CEGUI-devil: Contains the DevIL based image codec module.
• CEGUI-freeimage: Contains the FreeImage based image codec module.
• CEGUI-xerces-c: Contains the Xerces-C++ based XML parser module.
• CEGUI-libxml: Contains the libxml2 based XML parser module.
• CEGUI-tinyxml: Contains the TinyXML based XML parser module.

While producing 15 packages might seem slightly over the top, I feel this allows us (or downstream packagers if they follow suit) to more accurately reflect the granularity of CEGUI - as opposed to a single monolithic package that either brings in dependencies that the user might not want or does not provide the module(s) that they do want. Typically an end user would install some app that uses CEGUI which will correctly bring in only the modules needed - which in 99% of cases will be the CEGUI package and one of the renderer packages. For a developer, again you will typically need the CEGUI-devel package and a -devel package of the renderer you're going to be using. The lua support package is probably one that could get used quite a bit. I only anticipate rare cases when the other packages would ever be needed in reality.

The spec file that we commit will have been produced on a fedora 12 installation, so there may be minor alterations required for support in other distros. Also of note is that the first version of this new .spec that gets committed will not be the 'final' version, because we'll be adding some missing bits (documentation) and probably making the overall process more configurable.

I have a view to commit the .spec file tomorrow, comments before and after the commit are very welcome

CE.

[emarcotte]

Having more packages is better than less by far.

I hate when I go to install something with optional deps and oh look i'm pulling in the whole stack of stuff I don't need. This is definitely the right way to go.

[CrazyEddie]

Cool. Thanks for the support for 'lots' of packages I did not get around to finishing the .spec file as yet, but hopefully will today.

CE.