Enter the pluggable wrapper script. It would be event based, interfacing (almost) seamlessly with pacman, and allow you to enabled and disable wrapper functionality, such as srcpac.
Going with my "wrappers are a hack" theory, you're just legitimizing a hack as the official "plugin" system to Pacman. Pacman should eventually allow plugins natively if you really want this. This would probably be the solution to all of our problems, as you choose the features you want.
I don't think pacman should eventually allow plugins. There should always be a simple way to get to the basics of package management. I also wouldn't want to write pacman plugins in C. And, to take one of your excuses, "suddenly we'd have to install 10 plugins just to get pacman up to snuff".
Jason, I don't think your first two statements are mutually exclusive. You can have both.
Here's the summary of my input: I agree that having 10 plugin packages to install would be annoying; however, just because the program is internally structured to use plugins doesn't mean you have to package it that way. If it makes sense for stability and simplicity to package the plugins into the single pacman package, that's fine.
So I guess my suggestion would be to define a C plugin API, define APIs for plugins in other languages where you feel they're necessary (structuring it as a "bridge plugin" between that language's plugin API and the C plugin API), and then carefully manage the plugins that you let into the main source tree. If you wanted, you could structure the system so that the list of plugins actually gets compiled into pacman, so people *can't* add plugins without distributing a whole new pacman package.. which they could still do for testing.
I'm pretty sure the plugins for other languages point is a sticky one... we don't want to have pacman compiling in a python interpreter just to use some plugins. Though I do like the idea of being able to statically, at compile time, define your list of plugins to be shipped. That's kinda cool.
The thorny areas: How do you make sure you've got an interpreter for each kind of plugin API? Which languages do you choose as other languages for APIs? How do you structure the API to give the right level of flexibility?
Those are the tough questions. I already answered one by saying that building an interpreter into pacman is not an acceptable option. That still leaves options like pyrex though. The API is an even more difficult problem. I only have a vague idea. So then, if you were a plugin API for a package manager, what would you look like?
So all this sounds like a a lot of work, though probably actually less than it sounds. Perhaps in the short term, a "wrapper API" might be the way to go, as Jason seems to be suggesting. My question is: exactly what do you mean by "event driven"? What exactly would be the interface between pacman and and the pluggable wrapper script? How would it survive changes to pacman itself? How would we keep the pluggable script in sync with the current version of pacman?
It would be event driven because each module that wanted in would register itself to receive different events in the pacman process. If you look at how srcpac wraps pacman, srcpac becomes a command of itself. It only calls pacman when it needs to. The design of srcpac allows it to ignore any functionality that doesn't affect its own functionality. Any groundbreaking changes with pacman would need an upgrade to the wrapper framework.
The really nice part about a plugin structure is that it encourages other people to extend pacman, because it will be easier to do so. I think ethereal is one of the classic examples of this phenomenon. Then the extensions that you like and are stable can be integrated into the main tree.
I've never looked at the ethereal plugin system ;) Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.