On Mon, Aug 30, 2004 at 11:54:46PM -0500, Ben Mazer wrote:
On Mon, 2004-08-30 at 14:55, Jason Chu wrote:
There are two conflicting schools of thought with respect to adding features to pacman: - everything should be written into pacman, because there's less to worry about that way - everything should be a wrapper, because it complicates pacman less
Actually, three schools of thought. This would be mine: - some things should be in a wrapper, some things should be in pacman
Almost everything I've seen brought up so far I thought should go in Pacman. Now you know me, I like things light. But most of the features are important enough to be in pacman proper. For example, I think rollbacks and orphans should be in pacman.
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.
There is a related issue to wrappers though: if you have more than one wrapper that do complimentary things, shouldn't you be able to run both of them at the same time?
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).
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...
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".
Of course Pacman couldn't be a plugin/library interface for a very long time, but I'm saying this is a bad road. I guarantee you that if you make a wrapper framework and begin writing lots of wrappers, this "hack" will become permanent, and cause innumerable issues (the slackware example again).
I believe you wanted to use the auxiliary verb "can't", "couldn't" meant that it'd only be a plugin/library interface for a short time. You wouldn't be writing lots of wrappers, you'd be writing lots of modules. I don't see how the slackware example fits here. We're not talking about different package managers and different repos. We're talking about added functionality.
My two example cases were srcpac and rollbacks. Rollbacks could be implementable through such a system, but I'm already told it'll be going right into pacman itself. Another example is regular expression searching.
I've already stated other places that I think RegExps should be in the pacman proper (if they're deemed worthy enough). Why? Because they conflict with an existent Pacman feature (Search). Now instead of just adding features, you're going to modify existing ones? This could become like Perl, with Wrapper dependency hell. Wrappers will start to implement "essential" features, so wrappers will depend on one another. Then you'll need 10 wrappers working together just to get Pacman up to suff.
Conflict with features? Did you look at how it was implemented originally? He added a new arg to pacman. -Sx would search using regular expressions. The idea is never to implement an "essential" feature with a wrapper. If regexps aren't deemed worthy enough, then do they go the way of the dodo? Do we just ignore them because they're not pure enough to go into pacman proper? I never said things that should go into pacman would go into a module instead. I'm saying things that don't need to go into pacman could be in a module instead.
What does everyone think of this idea? Is there enough demand for different functionalities that would be nice for some people but annoying, problematic or just stupid to add to pacman?
Plugins would be nice. Do it right or don't do it at all (:P). But like I said, most of the requested features I like, and think should go into pacman. The others I think shouldn't happen in any form. I do think Srcpac should eventually become part of the default Pacman distribution, just like Makepkg/ABS.
"right" is a relative term at this point. I don't disagree that most of the requested features probably should go into pacman, but there are others that don't need to. Why is srcpac an exception this whole time? I don't see how you can say, "wrappers are evil and should never exist! but I love my srcpac!" 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.