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:
- Manually download all the *.apm tarballs.
- Unpack each *.apm tarball into an appropriate temporary directory somewhere, either manually or using the ACS APM web UI.
- 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.
cvs importto import the package files into my local CVS repository with appropriate vendor branches, tags, etc.
- Go over to /web/mysite-dev/packages/, do a
cvs update -d PACKAGE-NAMEto 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
cvs -d cvs.openacs.org:/cvsroot export
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.
The APM is far from ideal. If one were starting from scratch, one might hope to do better (though for a first effort by folks who'd never done anything like this before, it's not bad).
We have *many* important issues to think about in regard to OpenACS 4. IMNSHO (NS=not so) there are issues that make the toolkit, as it exists today, close to unusable. Look at some of the threads regarding performance of the bboard system. Look at the three new threads on admin UI. Think about the private laundry list I've been building that I'll spring on the community after we hit a solid beta release and can start thinking about a second release cycle.
If I start thinking about prioritization of effort, rewriting the APM is way, way down the list. Tweaking it within its current framework will be necessary, for sure. But rewriting it into something like the BSD Ports system? This is a non-trivial task ...
In practice, it's my intention that our releases include "clean" versions of all packages the community supports, in a single tarball. My guess is that the vast majority of users will just use the tarball, and totally ignore the fact that you can download APMs individually.
People who want to stay up-to-date will, as suggested, are probably as likely to visit the CVS repository as anything.
This is one reason why I place "replace the APM" at a low priority.
Note that I'm not saying it would be a bad idea from an idealized ivory-tower vantage point. I just can't see it being important enough to deserve our putting resources into replacing it with something better for many, many months.
If you're looking for an opportunity to help ... we can give you work. Lots of work. That's no problem :)
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).
want to start redesigning the APM now! But since it came up, I'm
still curious to hear people's thoughts on what a good "ivory-tower"
solution would be. Not because it makes sense to do that stuff
anytime soon (or even in the forseeable future!), but just because I
think some of us - like me - could learn from the discussion.