On Tue, Oct 19, 1999 at 09:55:57AM -0400, "Shawn P. Wallace" <shawn@xxxxxxxxx> wrote:
> >
> > Of course, a simple gimptool wrapper plus some archiving database (the
> > registry!) might suffice.
> >
>
> It doesn't seem as if Gimp development has the critical mass (read:
> sheer number of module developers) that Perl has.
Well, I'd say installing one hundred plug-ins via gimptool, Makefile
tweaking and worse has the critical mass to require something like cpan to
install modules.
> expansion/tweaking of the registry would suffice for now, but perhaps we
> should be thinking of the NG Plug-in Registry, which should probably be
> modelled on CTAN/CPAN.
I'm fine with the current _storage_ model (files in the registry), I'm
looking for an easy way to install additional plugins.
However, what we should think of in _any_ case is a revision of a "what is a
plug-in" on the registry. I'd say either:
- a single .c file (with absolutely NO portability requirements whatsoever),
[deprecated ;)]
- a .tar.gz, which includes source, a Makefile.am and configure.in. If either
of these is missing, some standard way to regenerate these (i.e. write a
standard configure.in and Makefile.am for that case).
This allows us to package .po files &similar to the plug-in.
- a xxx-architecture.tar.gz (or .zip), containing a precompiled version
for a specific os (e.g. somethine like redhat-6-x86, aix-4.1, suse-6.2-axp
etc..) that would allow us to support the most common targets with ~99%
success rate without user intervention.
(we could copy CPAN's proposed standard for binary modules here)
Having a wrapper (like the cpan shell) would also allow us to retro-fit
extensions like better i18n for plug-ins (like storing and merging po files
on installation) independent of the module authors or users.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
