[arch-projects] Pluggable wrapper

[Ben Mazer]

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. -- /.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://archlinux.org/pipermail/arch-projects/attachments/20040830/45d3a296/attachment.pgp>