Allegro 5RPM

Allegro 5RPM

bamccaig

Member #7,536

July 2006

(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. :-X

--
I mean the best with what I say. It doesn't always sound that way.

SiegeLord

Member #7,827

October 2006

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

8-)

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

bamccaig

Member #7,536

July 2006

--
I mean the best with what I say. It doesn't always sound that way.

Mark Oates

Member #1,146

March 2001

Give a man a fish... sigh. ::)

--
Visit CLUBCATT.com for cat shirts, cat mugs, puzzles, art and more <-- coupon code ALLEGRO4LIFE at checkout and get $3 off any order of 3 or more items!

AllegroFlare • AllegroFlare Docs • AllegroFlare GitHub

bamccaig

Member #7,536

July 2006

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 mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias

Member #358

May 2000

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

--
"Either help out or stop whining" - Evert

Evert

Member #794

November 2000

Elias said:

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).

bamccaig

Member #7,536

July 2006

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.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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.

bamccaig

Member #7,536

July 2006

Ah, true. Very good point. :-X 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.

--
I mean the best with what I say. It doesn't always sound that way.

MiquelFire

Member #3,110

January 2003

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.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

bamccaig

Member #7,536

July 2006

MiquelFire said:

I think you're right. Good catch.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

You probably also want to provide separate debug packages too.

(no-one ever said packaging was simple)

bamccaig

Member #7,536

July 2006

You're probably right too, Thomas. :-X 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).

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

bamccaig said:

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.

bamccaig

Member #7,536

July 2006

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. :-X

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.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

bamccaig said:

Apparently the Fedora guidelines discourage the use of lots of scripting in RPMs and prefer you to patch the upstream..

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.

Quote:

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..

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.

bamccaig

Member #7,536

July 2006

Thomas Fjellstrom said:

Thats kindof annoying. Does that mean actually submit those changes upstream? or just keep patches along with the srpm?

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.

Thomas Fjellstrom said:

And allegro's debug libs are named differently so they can't effect most apps at runtime.

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.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

bamccaig said:

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.

bamccaig

Member #7,536

July 2006

Thomas Fjellstrom said:

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.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

bamccaig said:

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.

Peter Wang

Member #23

April 2000

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.

bamccaig

Member #7,536

July 2006

OK, now I have a spec file that builds RPMs. In fact, it somehow also built a -debuginfo one... :-X 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). :-X 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.

--
I mean the best with what I say. It doesn't always sound that way.

Matthew Leverton

Supreme Loser

January 1999

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.

--
RTFM | Follow Me on Google+ | I know 10 people