Forum OpenACS Development: APM - RPM *.apm style vs. BSD ports style?

My own view is that the package manager doesn't suit our needs. It is not important to package up individual applications into standalone distribution files (*.apm) so that they can be installed willy-nilly. In fact I think it's detremental to the goal of producing an *integrated* tool kit (you don't have to look far to see the wheel re-invention...)

The problems discussed in "How do you separate project customisations from improvements?" are faced by each of us, but we have no tools to help us manage the complexity. A FreeBSD style system using CVS rather than the RedHat style package system we have would be more appropriate.

That seems like an important and interesting enough point to start a new thread about.

In practice, I find that the modularization of APM packages is great, but their packaging up into *.apm files is more of a hindrance than a help. My normal procedure for installing and using APM packages goes something like this:

1. Manually download all the *.apm tarballs.
2. Unpack each *.apm tarball into an appropriate temporary directory somewhere, either manually or using the ACS APM web UI.
3. Remove any bogus CVS directories, or otherwise clean up any minor screwups made by the person who packaged up the files into the *.apm tarball.
4. Use cvs import to import the package files into my local CVS repository with appropriate vendor branches, tags, etc.
5. Go over to /web/mysite-dev/packages/, do a cvs update -d PACKAGE-NAME to get the actual code into my ACS, and then install the package, load the data model, etc. from the APM UI.

Granted, you only have to that once per package (and per release...), but it's pretty much the only right way to do it, and it seems unnecessarily difficult and error prone. It would be much simpler just to eliminate all use of *.apm files altogether, and do something like cvs -d cvs.openacs.org:/cvsroot export openacs-4/packages/one-package instead.

Now, I actually can get all OpenACS code via CVS now, so in the future, personally, that's the way I plan to do it.

But, back to Stephen's original point. He was suggesting that we'd be better off to use a *BSD style Ports system, rather than the Red Hat rpm style package system the APM understands now. This sounds plausible to me, particularly since my experience is that using any rpm package-style system without a tool like Debian's apt-get just totally sucks. And I love Debian's package system (and apt-get!), but if I was actually hacking on some of the code, rather than just auto-magically installing precompiled black-box binary packages, it might get annoying. But on the other hand, I don't know much of anything about the Ports systems used by FreeBSD, OpenBSD, etc.

So Stephen, could you fill us in further on how the *BSD Ports systems work, and in particular how using something like that might be good or bad for OpenACS?

For example, maybe one drawback would be that for an outside developer, making his code available via this Ports thing might be harder then just slapping up an *.apm tarball on a website somewhere.

But like I said, I've never used anything like that, so I'm interested in what Stephen and other OpenACS folks who have used *BSD style Ports systems have to say.

We will also want to provide upgrade .sql scripts for tagged releases after we hit beta (during this alpha-ish stage my philosophy has been "all bets are off", but that will need to change, as was pointed out in a recent thread).

This would lead to a situation where you can delete a package's files, grab the latest from CVS, stuff them in the right place, run the upgrade script, and be on your way.

In theory ... I've been worrying, as I dig further and further into this beast, that we may need to do some fairly serious mucking about the datamodel in ways that will make upgrading painful (as Stephen points out elsewhere, acs-objects and the CR don't always play well together, and IMO more generally the CR is too closely tied to the CMS package).

Ugh ...