Forum OpenACS Q&A: Community Bid: RPM's for RedHat

Detailed demands:

• RPM which installs if postgres and aolserver have been installed (as RPMs that is, take the ones from RedHat as a basis unless there is serious reasoning against it).
• OpenACS RPM will fire up the webserver on localhost:8000 and greet the user with the page where he could give his personal details (the end of the installation screen).
• If localhost:8000 is busy, take another open port

Well, money for it, huh. As RPM maintainer for PostgreSQL, I can say this much: if I were to do up a set of RPMs for OpenACS+AOLserver for pay, it would take more than 100ドル to get me to do it. But that's just me.

When I built PostgreSQL RPM's for Great Bridge I got that much per hour -- and it took many hours.

Having said that, most of what you want can be done, and I was planning on doing it. If I get there first, I wouldn't mind the money, although it really isn't necessary to give me any money, as long as I'm doing it for open source purposes.

Now, your specific requirements:
First, AOLserver RPM's will need to be built. This shouldn't take long to do, actually. The hard part is making them LSB compliant.

Next, requiring AOLserver and PostgreSQL from RPM is reasonable, and very easy to do with RPM's 'Requires:' structure.

Now, the second requirement is a little more dicey. The 'personal details' would include, I presume, the name for the server, where to put the data, etc. Then it would need to copy the default instance of OpenACS to the target directory, create a database with proper permissions (and if necessary create a user for AOLserver in the database), and then write out a .tcl config file for that server instance. It would be up to the user to determine how best to start the actual OpenACS server, though.

Now, this same web script would be useful for creating ANY OpenACS instance, not just the first one....

Anyway, it's more than 100ドル worth of work, IMHO. But I was going to do it anyway -- just haven't had the chance. If somebody else gets there first it won't hurt my feelings, either. 😊

It seems like there are several ways we can install OpenACS.
Currently we have tarballs and CVS. Now we're adding in RPMs.

In some ways it seems like RPMs are the best way we should
be doing things, because it makes it so easy for newcomers to
get started.

However, how do RPMs act when you've modified portions of the
source code yourself? When someone installs the RPM for
OACS 4.5, makes all sorts of modifications, and then tries to
install OACS 4.6, is all their work going to be lost? Or are they
going to lose the changes in the files that are modified?

It seems like in the past that RPMs were kind of the "underdog"
way of installing OACS. If someone had a problem and they had
an RPM install, people would respond that really they should just
install from the tarball or CVS. But maybe my memory is
deceiving me. If this is the case, then we should be really clear
with people that RPMs are just a quick way for people to check
out OACS, and that to do any REAL work, you need to install it all
manually.

Perhaps the RPM should have a core part and a part that is fed
by CVS? I don't know that much about packaging up RPMs, so
I'm not sure what the exact nature of the problem is, much less
the solution. Any comments?

But, you are right, if you heavily customize your OpenACS installation and install an RPM of the next version, it is a non-trivial (impossible?) problem for the package manager to avoid screwing up your changes, *especially* if they involve datamodel changes.

if you upgrade a customized product you'd never use RPMs, at least not to my knowledge. RPM's are there to get you started. We might though have this .rpmsave functionality with an upgrade, that would identify files changed from the former RPM and save them to a special file with a .rpmsave extension. But you'd not use CVS either, because this would not work well with your changes.

I think upgrading should be handled by the APM, but that's just my gut feeling.

the 100ドル are just reflecting the value an RPM would have to us as a company, more specifically how much I'd be willing to invest so we could use the RPM to put it on distributions (if possible), but at least make it OpenACS easier to install / checkout => Generating more interest (continue the rest of the cycle at will). It does in no way reflect the real effort in this.

I made Debian packages for AOLserver 3.3ad13 with Tcl 8.3.2 (regular) and 8.4, (which is segfaulting right now).

I also made packages for aolserver-postgres (updated, improved docs), aolserver-xml, aolserver-openssl, aolserver-docs and aolserver-dev. I will be making OpenACS Debian packages shortly.

I then converted my Debian packages to RPM using the "alien" Debian tool, and they turned out quite well. There are two dependency issues that I need to solve with the -postgres and -openssl RPMs.

The AOLserver Debian package asks a couple questions and then gives you nicely started AOLserver on th port you chose. This thanks to the aolsrvconfig script that Brent Fulgham (original AOLserver Debian packager) converted from Apache's apacheconfig debian package script.

I'd appreciate testers for both these sets of packages (Debian, RPM). They are available (through apt-get for Debian) at 'deb http://www.brasileiro.net/roberto/debian as33/' and as33tcl84/. The RPMs are in the same directories (/roberto/debian/as33).

bduell on IRC requested the .src.rpm's. I'll put them there too.

<p>
To answer a couple of questions/concerns/points about an RPM
install:<br>
1. As I envision an RPM install, the master copy of OACS would go
into /usr/share/openacs. There would be an adp tree in there for
the functionality of setting up an instance --
/usr/share/openacs/setup-instance/index.adp for start.
<p>
2. There would be a 'setup-instance.tcl' AOLserver config file in
/usr/share/openacs/setup-instance that would start the 'setup
server' on port 8000 or whatever, with a webroot of
/usr/share/openacs/setup-instance.
<p>
3. You'd point a browser at localhost:8000 and get index.adp, which
would walk you through setting up an OpenACS instance. Now, the
logic in index.adp will be quite complex, and it will need helpers,
etc. But those are details.
<p>
4. Each instance would go into /var/lib/openacs instead of /web.
/web is verboten for an LSB-compliant installation.
<p>
Now, when you upgrade the openacs RPM, you only touch the master
instance in /usr/share/openacs -- the stuff in /var/lib/openacs is
untouched, and can be upgraded by, perhaps,
/usr/share/openacs/setup-instance/upgrade-instance.adp.
<p>
Does this answer the concerns raised?

That said, RPMS suck and LSB sucks even more. To me its the old how do we get windows users to switch to linux, answer you don't. If people aren't willing to install from source they are going to have problems.

I think putting every instance of acs in /var really sucks because then you have to give users permission to /var/theiracs. In reality installations should be in /home/user/acs. This actually follows the FHS as the program is really user data not system data.

One of the big drawbacks of RPM is non-interactivity. You can't ask the user questions so all you can really do is setup a default acs in some directory and then copy the files to the new server. In this case what does RPM buy you? As noted above, you lose any changes you made on upgrades unless you mark files.

All in all, I personally feel that RPMS may be good for letting someone make a test server to get a feel for the components but I don't see how RPM will significantly increase our user base. It is a technical issue, and you will have to have some technical ability to use it. Not everything can be packaged and be usable.

Now if you want to talk about the marketing aspect of having an RPM that is a different matter, it may get some people to try it, but again after they set it up....

Just my thoughts.

Plus, you can create kick-start files so that bringing up a server complete with all software needed takes no more effort than a couple of clicks, and you're garanteed that nothing will be forgotten.

Plus, you have an easy way of checking the integrity of the installed software, packages that need updated etc.

The toolkit itself is hard to package because it's a set of source code which one is expected to modify, and the only sane way to upgrade that is with a source code control system, i.e. CVS. RPM, DEB and APM just can't handle it.

That's why I think there should be two OACS packages: oacs-sneak-peek and oacs-toolkit.

The sneak peek can be made immutable, enabling packaging, and could be additionaly modified to for example make all users site wide admins, pre-mount a bunch of packages etc.

The oacs-toolkit would be a collection of scripts that encapsulates the typical working method of a professional ACS developer using CVS. What's that Linus quote I see in sigs? "I will replace you with a small shell script"

That would truly rock.

talli

Next I will do an aolserver, OpenACS I will have to think about. The good thing about ebuilds is they can be interactive.

"The good thing about ebuilds is that they can be interactive." Indeed that is good, and Debian packages have that 😉

From speaking with Roberto, I think that the portage and apt-get are more or less functionally equivalent but just take different approaches. Having both an gentoo package and a debian package that would allow for OACS install, or at least OACS component installs, would both truly rock.

talli