Wildfire yum repository, when?

Wildfire is cool but it’'s too hard to update it at every release. It is very simple to release new RPM in a yum compatible repository. This way all interested users can setup yum for checking for updates.

Sorry there is no such a great thing like yum for Windows.

Please post your opinion if interested.

and i wish a package for a pacman (Arch Linux) There are various packages already, and if one need some specific package, then the one should create it. So, there should be a yum rpm wildfire maintainer.

On that same note- if community members create packages, will the JiveSoft people host them? I can make a debian package, for those running Debian/Ubuntu or some other related distro. Or even better, if I can set up the debian directory (the equiv to the rpm spec file) will you accept that into your subversion repo and build it yourself?

OT: Forums are showing me online (XMPP) though i have logged of my Psi long time ago.

EDIT: after clearing Firefox cache it now shows correct presence icon.

slush,

As long as we can drive the build process through Ant (our build tool), we’‘d be more than happy to include additional build options. We get a lot of feedback that the RPM files could be a lot better as well. Unfortunately, we don’'t have a lot of control over them at the moment since they get automatically built by Install4J. So, that might be something to improve as well.

Regards,

Matt

Im sure I could hack something, provided that the build was run on a Debian system. I might be able to hack something even worse if you cant run in on a Debian system (the debian package format is easy enough to create with standard utilities). Is Jive willing to run a Debian system to generate packages? I know you have a VMWare image of it for testing…

I might provide it even if you dont, so that I can make my own packages…

Hi Matt,

I’‘d love to see that you don’'t offer RPM any more. Writing a short tutorial on how to extract wildfire.tar.gz should be very easy and all users should be able to do this.

LG

Im sure I could hack something, provided that the

build was run on a Debian system. I might be able

to hack something even worse if you cant run in on a

Debian system (the debian package format is easy

enough to create with standard utilities). Is Jive

willing to run a Debian system to generate packages?

I know you have a VMWare image of it for testing…

I might provide it even if you dont, so that I can

make my own packages…

Our ideal is that the build system is 100% cross platform and can be run via Java. However, we’'ve already started violating that – Spark has to be built on a Mac to get a nice DMG. So, order of preference:

  1. Totally platform neutral build of Debian package.

  2. Build script that requires Unix due to scripting, etc.

  3. Build script that requires Debian.

However, I would say that having a very polished installer and simple to maintain (rather than simple to run) build system is even more important than the preferences above. Adding more infrastucture to our build environment by using something like VMWare isn’'t the end of the world.

Thanks!

-Matt

I’‘d love to see that you don’'t offer RPM any more.

Writing a short tutorial on how to extract

wildfire.tar.gz should be very easy and all users

should be able to do this.

We’'re all about choice. So, although tar.gz is pretty simple, using an RPM is even easier for many users.

Regards,

Matt

Hi Matt,

is “using an RPM … even easier for many users”?

Or does it just seem to be more easy? You have no real control about what Install4J does and don’'t know how the users start Wifi, look at http://www.jivesoftware.org/community/thread.jspa?threadID=17379 as one example.

I’'d like to see one install & upgrade guide for the tar.gz version. And as no one has time to maintain also a RPM install & upgrade guide it would be imho a good idea to offer it no longer. But maybe we get a http://wiki.jivesoftware.org/Wildfire page to write some public documentation.

LG

I agree with LG that perhaps the RPM build is bad, and thus should be pulled. It seems to be apart of an automatic process that isnt tested well. Im all for providing packages, but they should be useful to people.

My preference would be to improve the RPM rather than just getting rid of it. But yeah, it’'s not good in current form.

-Matt