Openfire

Hi folk! This is an ongoing process, so you will see this issue move a couple of times until we consider it "complete". I have a number of things in the works that I'm going to begin documenting internally. But to give you a quick summary.

1. I'm looking to set up hosted yum and apt repositories, that admins can point directly at, run by us basically
2. Investigating the many distributions out there and seeing where people are already building dists for us, or where we should get our foot in the door, etc
3. Maybe even offer to take over a couple of the builds for certain distributions

I'll try to keep you posted as things progress! Probably via this issue. =)

See http://mcepl.fedorapeople.org/rpms/openfire-3.4.4-1.fc9.src.rpm – that's my first initial attempt of packaging for Fedora. It is still not what I would like it to be – too much stuff from your tarball which should be used from the system packages. But it seems to work, although it doesn't seem to be as stable as ejabberd on the same computer. I will try to put it on the diet a little bit more, build it in mock (I am not sure whether xxx succeeds; if it does, we have package which is buildable on Fedora/Rawhide with IcedTea).

Concerning your previous comment – I don't think it is a good idea, to make your own repository. Just cooperate with the downstream maintainers (like me ) to keep openfire packages inside of the downstream repositories. Then your users don't have to fiddle with yum/apt/whatever configuration but just run their native installation procedure (yum install openfire in my case).

Will keep in touch.

Sorry, forgot to add URL to the koji build http://koji.fedoraproject.org/koji/taskinfo?taskID=365939

chuckle I'd have to disagree. Plenty of folk have expressed quite a bit of excitement in us having our own repositories. And putting on my sysadmin hat a moment, I always prefer pointing at the vendor's own stuff instead of using whatever came from the distribution. (like frankly I like /opt/openfire and a bundled JRE over the openfire dist being scattered all over the file system and some JRE that I don't know that the vendor hasn't tested =) ) That said, I know a lot of folk have the opposite thoughts on it, so I feel having both options would cover both bases.

So regarding downstream maintainers ... are you volunteering to keep the Openfire Fedora RPM up to date? ;D

a) yeah, sure that's the point – I am a maintainer of the couple of packages in Fedora (none of them by far the size of openfire though, and none of them in Java), and I would like to maintain openfire in Fedora, so that we have both leading XMPP servers in (actually, ejabberd is now in pretty rough shape in Fedora/Rawhide, because of beta version of both ejabberd and erlang).

b) I have of course no problem with you maintaining your own version of the package – and I don't care that much about moving files around, that's the least of all problems.

c) What I would really like to clean out in your package is not using local packages for something we have in the distro already packaged. Not only it saves a lot of space (just by removing Sun JVM I saved 20MB; and there is just no reason in the world we should ship one more ant.jar with XMPP server), it is a maintenance nightmare to fiddle with all those duplicit libraries. I remember when development of Debian stalled for couple of weeks, when a security bug in libz was discovered, and everybody was just searching and fixing all those packages which used local copy of libz. One of the first things RH people changed in the IcedTea was that it now uses glibc version of time-data format, so we don't have to fiddle with Java whenever some politician decides that the current timezone of their country is not good enough for them.

And I guess that just by removing all .jars which are already present in the system won't be enough, right? I will have to patch (at least) build/build.xml, right? I am not a Java programmer, so I don't know, if for example just by removing path specification from build.xml, right (i.e., ant won't look for them in the standard locations)?

BTW, why I cannot find an open MUC for openfire-related discussions. The ones on conference.jivesoftware.com seem to be per-invitation only, which really doesn't foster community development. Couldn't you open at least community@ MUC, please? It looks really weird, when you have community only for invited.

open_chat@conference.igniterealtime.org is the main muc room for chatting about igniterealtime products =)

Yeah, I know about open_chat@conference.igniterealtime.org, but it would be nice if somebody was there .

More distribution locations have been located and recorded. We have worked out where we are going to serve the yum and apt repositories, but have not figured out the proper procedure. Haven't heard from the Fedora 9 contact in a bit, need to see how things are going on that front.

Sorry, the contact (that's me) was told by the administrators of of the part of the internal network where I planned to install the Jabber server, that OpenFire being Java app is too big for the internal network comparing to ejabberd which is apparently much more lightweight (there is currently not that many users of the server, so I won't get a dedicated server for that).

So, when I won't get answer to any of my questions I asked (see <http://www.igniterealtime.org/community/people/mcepl?view=discussions>) and I had to learn to use ejabberd anyway, I more or less stopped working on openfire packaging anymore.

=(

These things happen. Thanks for your input none-the-less! Good luck with your new setup!

Still, I would be interested in the answers to my questions – although in this particular project I won't use openfire, I consider it in same aspects (not hardware requirements, I am afraid, though) to be superior to ejabberd. For small server with sufficient hardware available it could be really good match (if I didn't have the problems I mentioned in the other threads).

Hi, I am also a Fedora packager, and am interested in ironing out these issues. I also know Java pretty well, so that should help.

I would say that the biggest issue I see here is that the "source" tarball has a lot more than just source in it. Not that it's a big deal, but Fedora has to build everything from source by policy anyway, so the extra jars and things don't help. Also, having a smaller upstream source release helps the Fedora mirrors, and avoids problems with shipping of things that Fedora might not be able to redistribute (like a JRE).

Any jar file or binary library you ship in your source tarball would have to be separately packaged in Fedora if it is not already. But that's no problem, I (or whoever packages it), will go through and package all the dependencies too. This was done for Eclipse, which was a pretty long process, but allows Fedora to guarantee that anyone can rebuild any of Fedora from scratch.

Maybe a good start is to figure out what can be split out of your source tarball.

Hi, Adam,

just to note, that a) I am not a Java deloper, b) I gave up on Openfire (and running my own JAbber server), so openfire in Fedora is probably all yours to play.

Update: In addition to seeing OpenFire in distribution channels, I would very much like to see an RPM download which does NOT include a JRE. I'd prefer to rely on my OS or update channels for keeping the JRE current.