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).
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). 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. 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.
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. 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).
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.
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. Ben -- I was overjoyed when, having bought a Fujifilm camera, I realized I could justify having /mnt/fuji on my system. -- /.