Basically, if a feature is important enough to write a wrapper for, it's important enough to be in Pacman, most of the time. Prove me wrong, but so far no one has.
SRCPAC is a bit different. All the source management tools in Arch are actually BASH scripts. So writing Srcpac in BASH was a logical step. Unless you plan on integrating ABS/Makepkg into Pacman (don't), keep Srcpac as BASH too (or Python :P).
I think that's contradictory. "Anything important enough to write a wrapper for should be integrated in pacman." "Srcpac is a wrapper but should stay a wrapper."
srcpac was written in bash because of the simplicity of the functionality not because it called other bash scripts.
I recognize this contradiction. I guess what Ben really meant is that there's an important set of functionality that should be integrated, and things that can be cleanly separated and benefit from being implemented as a wrapper can remain that way. I guess I'm not yet sure how I feel about that.
If you have to run more than one wrapper at once, things have gotten out of hand. That's my opinion. This is where the conflict exists. People like things light, and fear featuritis, but we've seen programs that need a whole mess of things on top just to be useful. This is messy, and it pisses people off. One example is Slackware + all the 3rd party package management tools. Look how many there are. They're not all compatible, and almost all slackware users download them right after installing. If so many people use the features, they should be included by default (though Pat has them on ftp.slackware.com). This "unofficial" requirement has made large, compatible Slackware repositories non-existent. Compare that to Arch, Debian, et al. In fact, many people switch to Arch just for a Slackware + Swaret-like system (I know I and a bunch of people on the IRC channel did).
I definitely agree that things can get too complex and deep, and it is one of the reasons I use Arch.. to avoid that.
But I've heard you yourself say, "you shouldn't write a wrapper for that because srcpac is already a wrapper and we won't be able to use both of them at once." Paraphased, obviously.
The sorts of plugins to this wrapper would be added functionality that isn't necessary in pacman but that people bitch about. I'd rather not have a buggy pacman because some guy cried that his package manager didn't skip and jump.
This will cause issues, because each wrapper is essentially a hack, and it will always be that way until Pacman is made to a library, and the wrappers are written in a Language that can interface directly with C.
I hear that a lot too: "A wrapper is a hack, until it uses a library, then it's a good idea". So, how about it's first implemented as a hack, then when libpacman is released, the code is modified slightly to be an elegant solution? I figured it'd be written in python... python can do that sort of stuff...
Wrappers are also unofficial, by definition. You should never have to rely on two wrappers working together, because they are (in theory) written by completely independent people.
True, but with a framework and a properly defined API multiple modules could work together. That's the whole point. You're saying wrappers won't work together if they're written by independent people. Yes, I agree with that. But modules written for a pluggable framework could work together. That's why it's a pluggable framework...
I agree with this, Jason. I think that the "module" becomes a "hack" when it doesn't follow an API, not because it's written by someone else or because it's written in another language.
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. 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? 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? 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. - P