Forum OpenACS Q&A: SDM packages on OpenACS.Org for OpenACS RPMs?

I'm getting feedback and ideas from email to me regarding my recently released RPMs for AOLserver and OpenACS.

Before I either lose track of some of that, or implement bug/feature tracking privately here, could we consider adding Packages to the OpenACS.Org SDM for the three main RPMs I created:

  • aolserver
  • aolserver-postgresql
  • openacs

I recompiled libxml2 so it can be installed on stock RH 6.2, but I didn't do anything else to it, and don't feel a need to, so I don't see any good reason to put that into SDM.

Ben or Don, could you do this for me please? I've already got one change done that helps installs on RH 7.1 to work more smoothly...

I'm not sure how to structure this right -- each RPM a separate package in SDM's eyes, or one "OpenACS RPMs" SDM package and make each RPM a 'module' in SDM terminology? Since I may release each RPM independently from the others, I'm guessing separate SDM packages might be better?

Posted by Don Baccus on
Yes, we should do this.  I also need to set up a package for mod_nsd.

I'll have to think about the one-vs.-many RPM packages question.

IMHO it would be better to have separate packages for OpenACS and
AOLserver (with aolserver-postgres as a module). OTOH, wouldn't it be
better if the RPMs were hosted at This
should also be announced at aD's web/db, the AOLserver list and the bboards.
I don't mind where they go, although I've not really looked much as
the site yet at all, because the OpenACS community seems
to all just run AOLserver 3.2+ad12 anyway; my interest in packaging
AOLserver is primarily as a vehicle to get a simple easy "normal"
OpenACS install process for Red Hat (maybe other RPM distros later).

I'm not sure it is good to have aolserver-postgresql as a module of
aolserver, because they have two rather independent codebases; also,
releasing a new aolserver RPM to correct a packaging bug affecting RH
7.1 installations (which I am about to do!) should not also require a
release of aolserver-postgresql.  But in SDM, I don't see a way to
release "part of" a package.  And version numbering is (currently!)
different for the two RPMs, which again I don't think SDM can handle
on a per-module basis, only per-package.

So my conclusion so far is "3 separate packages"; if the feeling of
the team is that the aolserver and aolserver-postgresql RPMs should
have their SDM setup over at, that's fine by me.

I see that mod_nsd now has an SDM package, but not the RPMs.

Is there something useful I can do to help move this along?

Posted by Petru Paler on

There are no RPMs because there is no release of mod_nsd. Once the release is made (which I hope will be soon now), I would really apreciate if someone took care of the packaging...

I think Jonathan meant that there is no SDM package for the OpenACS RPMs. Is that right?
Posted by Ben Adida on
I've added a package for OpenACS AOLserver RPMs. The other
two packages will probably go on OpenNSD.
Thanks all.  Yes, Rpoberto, I meant SDM package(s) for my own already
existing RPMs for OpenACS/AOLserver/aolserver-postgresql. Apologies
for being unclear.

Thanks to Ben, the first of those now has an SDM home here on
OpenACS.Org 😊

Petru: You are right that someone ought to take on the role of
packaging the "Apache/mod_nsd/OpenACS" style of system.  Are those
who created the original RPMs in that form not keeping them updated?
I'll gladly pass on anything useful I have learned about packaging
OpenACS to them, but I'd much prefer not to do both myself, really 😊

On a related packaging note: did someone inform Brent about the
release of OpenACS 3.2.5, so he can build updated .deb packages for
those using Debian?  OpenACS SDM bugs #755 and #870 might also be
worth his looking at at the same time.

I e-mailed Brent about the OpenACS and AOLserver deb packages right before the 3.2.5 release, where I volunteered to update them. He has been busy and told me he'd e-mail me some resources, but apparently he is still busy, for I haven't heard back from him since.

I will ping him again.