> I'm not sure what you mean here... Do you need a different 'product' from > the GeoNode build than the current tarball or the upcoming RPM?
I'm thinking of the Java part (GeoServer and GeoNetwork). There are two approaches: 1 - simply packaging the WAR files (which include quite a few Java libs) in the RPM 2 - having separately packaged GeoServer and GeoNetwork, themselves depending on separately packages Java libs, etc. with everything building from source. (1) is much easier and is probably the approach that you are following (and the one I suggested). (2) is "cleaner" and has long-term benefits, but it is way harder. That's the JPP/Fedora approach, that we are currently trying to put in place. So, no need for a different 'product'... > I'm working with a contractor who knows RPM to bootstrap the RPM package, > hopefully it can become community-maintained once it is working in the first We have put in place a community around GIS packages on Enterprise Linux and we are now working actively with the Fedora and EPEL project: http://wiki.osgeo.org/wiki/Enterprise_Linux_GIS Don't hesitate to keep us in the loop for EL related stuff, I'm sure that there can be good synergies. Please also note that packaging is just one of our activity where we just complement EPEL. The main purpose is to centralize information and knowledge around FLOSS GIS software on Enterprise linux. > place. We'll announce this on the blog within the next week or so (the > package is still not "ready for primetime"), but the RPM packages are > already available at http://yum.opengeo.org/. I've attached a .repo file I tried to browse it or use it through yum, but it requires an authorization... > you can use to access the repository in yum (in order to avoid requiring > many additional repos we are mirroring some EPEL and ELGIS packages as > well.) Are you mirroring automatically? We are working a lot currently in the Java direction and for example we recently introduced GDAL JNI libraries in collaboration with Fedora packagers, which can be useful for optimal GeoServer usage. There is still some work to be done (we are putting in place automated approaches for JAI/ImageIO deployment etc.) and I would find it great if we could make sure that we are all working at the same pace and benefiting from each other progresses and tests!
