(Goddamn thread title... I thought the 5 and R looked kind of close...)

I'm going to be attempting to create an RPM for Allegro 5. I'm new to RPM though so my odds for success are somewhat questionable. Either way, I'm hosting the project on GitHub just in case anybody else wants to join in (perhaps somebody that already knows how to create RPMs, but any help is welcome).

The project is hosted on GitHub: http://github.com/bamccaig/allegro5-rpm

There's basically just a stub spec file and a helper script right now. It doesn't build an RPM yet, let alone one that works; let alone one that any distro would accept. Hopefully I can find time to make one that works in time... Or better yet, one of you can.

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt	(revision 14478)
+++ CMakeLists.txt	(working copy)
@@ -923,6 +923,15 @@
     add_subdirectory(python)
 endif(WANT_PYTHON_WRAPPER)
 
+set(CPACK_GENERATOR  "DEB;RPM")
+set(CPACK_PACKAGE_NAME "liballegro5")
+set(CPACK_PACKAGE_VERSION  "${ALLEGRO_VERSION}")
+set(CPACK_DEBIAN_PACKAGE_ARCHITECTURE "amd64")
+set(CPACK_RPM_PACKAGE_ARCHITECTURE "x86_64")
+set(CPACK_PACKAGE_CONTACT "AlexTheAlligator")
+set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Allegro 5 game development library")
+include(CPack)
 
+
 #-----------------------------------------------------------------------------#
 # vim: set sts=4 sw=4 et:

$ cmake .. && make package -j4
$ ls liba*
liballegro5-5.0.0-Linux.deb  liballegro5-5.0.0-Linux.rpm

Give a man a fish... sigh.

My goal with this project is to actually create something that Fedora (and possibly derivatives) will accept into their repositories. I'm not sure if a generic solution will suffice (though it's certainly preferred if it will).

I was planning on seeing what it would take to create a proper Debian package. Something that Debian would actually accept.

Oh, CPack looks nice. Does it support OSX and iOS?

Seems like it, although I'm not entirely sure how it deals with libraries: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators
I'll have to play around with that. From the look of things, this could be really useful (not just for Allegro).

I've been researching the Fedora packaging guidelines and such. I've joined some mailing lists that will hopefully help me to understand the process involved. I think that I'm close to understanding the spec file format so hopefully I can create a working RPM soon. I think that I'll probably focus on Fedora 14 since it was apparently released as stable 3 months ago. I guess my plan of attack will be to upgrade Fedora (i.e., full system reinstall) and before doing anything special try out my RPM to see if it actually does install everything necessary. Hopefully the package reviewers will be able to help me identify if I have extra packages defined. If they don't know then I might need to justify my dependencies, which will probably require some help from the Allegro developers. My WIP list is currently this:

BuildRequires:

• alsa-lib-devel

• cmake dumb-devel

• flac-devel

• freetype-devel

• gcc

• gtk2-devel

• libcurl-devel

• libjpeg-devel

• libpng-devel

• libvorbis-devel

• make

• mesa-libGL-devel

• mesa-libGLU-devel

• physfs-devel

• pulseaudio-libs-devel

Requires:

• alsa-lib-devel

• dumb-devel

• flac-devel

• freetype-devel

• gtk2-devel

• libjpeg-devel

• libpng-devel

• libvorbis-devel

• mesa-libGL-devel

• mesa-libGLU-devel

• physfs-devel

• pulseaudio-libs-devel

My naive understanding being that BuildRequires indicates packages needed only for the build process; .src.rpm to .rpm. Requires then is actually required to use the package. If you see something that doesn't make sense or notice something missing then please let me know. Hopefully I can get around to completing the initial build soon. AFAIK, I should only need to describe the build process now, which should be pretty straight forward thanks to cmake and make. I'm not entirely sure how RPM determines which files are installed and how to remove them (I know of no make uninstall option for Allegro's build system). I'd like to think that RPM installs to a sandbox first and determines based on that, but I'm too green to know.

You are going to want to split all the addons into separate rpms, which are only "Recommended" for the main rpm. So all of the addon dependencies aren't a "BuildRequires" or a "Requires" for the core lib.

Ah, true. Very good point. That's going to complicate matters somewhat. I think for starters I'll just try to get the whole of Allegro 5 into an RPM (i.e., what you get with cmake .. && make && su -c 'make install'). I'll worry about separating things later.

If the way Debian (and Ubuntu I believe) handles things applies to Fedora's system, then the Requires would be the binary install, and they should not rely on the devel packages. You would need a devel package to go alongside the main one.

I think you're right. Good catch.

You probably also want to provide separate debug packages too.

(no-one ever said packaging was simple)

You're probably right too, Thomas. That will probably be more complicated to satisfy though so I'll wait until I get a working RPM to attempt that (same as the addon and -devel packages).

It shouldn't actually be that hard. Its a single option when building, so it should be easy enough to support.

The debug packages would only include the libs.

Yeah, without having any practical experience, I think what I'll have to do for the various packages is build as normal (except where specific targets are available) and then strip out the excess... I'm not sure yet whether that will mean adding patches to the build system, adding scripts after the fact, or what... Apparently the Fedora guidelines discourage the use of lots of scripting in RPMs and prefer you to patch the upstream... So I'm not entirely sure how I'd have to handle it. I think the first step anyway is getting an RPM to build. Period.

I should note that installing -debuginfo packages seems to affect applications at run-time so I'm not sure if it's a matter of overwriting the existing libraries with the debug versions or if it's some other voodoo that I'm not yet aware of.. That is to say, if somebody were to have an Allegro 5 game distributed via Fedora's package repositories and somebody wanted to report a crash, the Fedora maintainers would want them to install the -debuginfo package so that the dump had symbol names and such instead of addresses. At least, from what I've gathered. I've only personally reported one or two bugs this way and was pretty blind doing so.

Thats kindof annoying. Does that mean actually submit those changes upstream? or just keep patches along with the srpm? Debian explicitly states they don't like upstream having a debian/ directory with pre-made debian packaging info in it. Most packages will delete that directory as part of its patching, and then build its own.

Depends on how its done. .so.debug libs don't effect apps at runtime unless run inside gdb or valgrind. And allegro's debug libs are named differently so they can't effect most apps at runtime.

I think the latter (though the former might be preferred in cases where the change is not Fedora specific). I assume you would include patches in the RPM (the spec format has patch fields) which would be run against the extracted source tarball. I'm guessing then that if you did need to do non-trivial scripting tasks that you would include patches to add scripts... I'm not sure yet. I still have a long ways to go.

Which is why I'm confused. Would I be expected to somehow copy/rename/symlink the debug libraries or what? I haven't taken the time to look for answers yet.

Course not. Either the apps link to the release libs, or they link to the debug libs.

Then how can installing -debuginfo packages add detail to crash dumps? AFAIK, the many packages that link to the library aren't updated when you install the -debuginfo package. Maybe the bug reporting application does a lookup in the debug libraries itself, but I'm not sure if that would be possible if the application was running against a non-debug version of the library.

In that case, if you wanted to support that, you'd have to rename the debug libs to the same as the main libs, except with an extension of .so.debug IIRC. Then GDB and other debuggers will pick up the .debug libs instead of the release ones when giving tracebacks.

Release libraries contain debug symbols, too, if you use the build configuration RelWithDebInfo (the default) and do not strip them when installing. You just do not get additional sanity checks within Allegro, which come with the Debug configuration (which also disables compiler optimisations, etc.)

By my understanding, the -debuginfo package would contain the debugging symbols stripped out of the libraries in the original package. It should not be replacing libraries.

OK, now I have a spec file that builds RPMs. In fact, it somehow also built a -debuginfo one... Not sure if it's correct or just some default that won't be accepted. Anyway, I still have a long ways to go separating them. If I run the core RPM through rpmlint then I get a ton of errors for devel files in a non-devel package.

** APPEND **

Am I to assume that these are all addons?

• allegro_acodec

• allegro_audio

• allegro_color

• allegro_dialog

• allegro_font

• allegro_image

• allegro_main

• allegro_memfile

• allegro_physfs

• allegro_primitives

• allegro_ttf

** APPPEND **

By my calculations there should be 39 RPMs in total for Allegro 5. Core library + 12 addons * 3 packages each (main, devel, debuginfo). Fortunately, it seems I can define them all in a single spec file, which probably means I'll only have to build once and then just specify which package each file goes to.

** UPDATE **

I think that I nearly have the files organized properly. I guess now I need to start testing it to see if it does what it's supposed to do. Then I can consider making an official review request.

Per advice, I've contacted the current allegro package maintainers and the one that replied sounded happy to let me maintain the allegro5 packages and is encouraging me to do it (as well as 4.4). So it looks like I might become an official Fedora packager for Allegro and Allegro-based games.

** UPDATE **

Please review the summaries and descriptions in allegro5-rpm-info.txt (the many Allegro 5 RPM packages). I don't really know what the various addons are for exactly so I had to bullshit a little bit. Once these are OKed I will submit my initial review request.

The descriptions seem correct.

I don't know that you should even include the allegro-main library. I think it's just an empty library on Linux.

Thank you. I've created a review request: https://bugzilla.redhat.com/show_bug.cgi?id=680205

You may be correct. IIRC, I was told in #allegro-dev that it should be used anyway for platform independent programs. I didn't actually bother to look inside it until now. It looks like it surely will be compiled down to practically nothing in Linux, but I guess at least the header files are still necessary to avoid warnings about them being missing. I wonder what, if anything, is even in the .so (and why it would be compiled at all in Linux)...

pepsi@fractalcmt:~ 01:48 PM $ ls /usr/local/lib/liballegro_main.so -l
lrwxrwxrwx 1 root root 22 2011-02-21 20:30 /usr/local/lib/liballegro_main.so -> liballegro_main.so.5.0
pepsi@fractalcmt:~ 01:49 PM $ ls /usr/local/lib/liballegro_main.so.5.0 -l
lrwxrwxrwx 1 root root 24 2011-02-21 16:45 /usr/local/lib/liballegro_main.so.5.0 -> liballegro_main.so.5.0.0
pepsi@fractalcmt:~ 01:49 PM $ ls /usr/local/lib/liballegro_main.so -l
lrwxrwxrwx 1 root root 22 2011-02-21 20:30 /usr/local/lib/liballegro_main.so -> liballegro_main.so.5.0
pepsi@fractalcmt:~ 01:49 PM $ ls /usr/local/lib/liballegro_main.so.5.0 -l
lrwxrwxrwx 1 root root 24 2011-02-21 16:45 /usr/local/lib/liballegro_main.so.5.0 -> liballegro_main.so.5.0.0
pepsi@fractalcmt:~ 01:49 PM $ ls /usr/local/lib/liballegro_main.so.5.0.0 -l
-rwxr-xr-x 1 root root 4074 2011-02-21 20:29 /usr/local/lib/liballegro_main.so.5.0.0
pepsi@fractalcmt:~ 01:49 PM $ nm /usr/local/lib/liballegro_main.so.5.0.0
000014dc a _DYNAMIC
00001628 a GLOBAL_OFFSET_TABLE
         w _Jv_RegisterClasses
000014cc d _CTOR_END_
000014c8 d _CTOR_LIST_
000014d4 d _DTOR_END_
000014d0 d _DTOR_LIST_
000004c4 r _FRAME_END_
000014d8 d _JCR_END_
000014d8 d _JCR_LIST_
00001640 A __bss_start
         w __cxa_finalize@@GLIBC_2.1.3
00000470 t __do_global_ctors_aux
000003b0 t __do_global_dtors_aux
0000163c d __dso_handle
         w _gmon_start_
00000467 t __i686.get_pc_thunk.bx
00001640 A _edata
00001648 A _end
000004a8 T _fini
00000348 T _init
00001640 b completed.5936
00001644 b dtor_idx.5938
00000430 t frame_dummy

Now that I actually look at the package contents, there's really nothing in the main addon packages at all... There's only the empty (for all intents and purposes) shared object file and its symlinks, and the useless (for all intents and purposes) .pc file... Not even a header file. Then again, perhaps the developers wanted for UNIX build systems to be able to still link to this shared object library (which does nothing) so that users don't need special OS X build rules? It looks like Linux-wise I could get rid of the main addon altogether, but perhaps the Allegro developers want it distributed anyway? Well?

Thats pretty much it. This way you don't have to special case linking. You can just link to allegro and allegro_main and call it a day.

Basically this, yes.
With allegro-main included in the linker options (through pkg-config), the same code compiles, with the exact same Makefile, on any flavour of UNIX, including Linux and Mac OS X.

You might want to place allegro_main in the main allegro package.

The allegro package maintainer (who is going to be sponsoring me if all works out) actually suggested that I merge most of the addons (basically any that don't pull in extra dependencies) into the main package. So no worries. That will be addressed shortly. Thanks for the help.