On Thu, 14 Dec 2000, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Lourens Veen <[EMAIL PROTECTED]> writes:
> > All true, but then the problem is that non-technical users have to wait
> > for someone (or their favourite distribution) to package new plugins.
> > IE, let's say I write a new plugin, put it on plugins.gimp.org in source
> > form. Then Joe User can't use it until Red Hat releases an updated rpm,
> > which may take a while. With the automatic building the plugin is
> > instantly available.
> > For distributing, this makes sense, but what about updates? I don't
> > think anyone would want to download a whole new tarball just to get one
> > new plugin. And if you're going to do separate tarballs, then what's
> > wrong with also creating a standard automated way to build and install
> > them?
> What's wrong with letting the distributors do their job and let them
> take care of creating binary packages? I doubt we have the possibilities
> to support all the various platforms out there. By releasing seperate
> tarballs we'd make it very esay for distributors to package plug-ins.
Yes, but that only works for Linux, not for other versions of UNIX
(although some sites act as semi-official packagers of third-party
software for Solaris or IRIX). My main machine is running Solaris,
and it would be nice if I could download and build plug-ins easily
from the sources. Also, it is not very likely that the Linux
distributors would create binary packages for their old releases. For
example, I have some PCs running SuSE 7.0, 6.4 and 6.3. The one
running 6.3 cannot be upgraded because some of my colleagues depend on
specific kernel patches and applications installed on that machine.
If I want to keep the Gimp up-to-date on that machine, I cannot rely
on the distributor to provide some plug-in packages (and the packages
for 7.0 would cause problems with the old libraries included in 6.3).
The packagers of Linux binaries should of course be able to build
their own packages containing the plug-ins, and the distribution
method for the Gimp plug-ins should also help them to do that (or at
least not get in their way). But they will build their .debs or .rpms
anyway, regardless of how easy or hard it is to get, configure and
compile the plug-ins.
I think that it is more important to standardize a method to build and
install from source, because that will enable everybody to try the
plug-ins as soon as they are released, and this will support many more
platforms than the ones that are actively updated by a distributor of
We already have gimptool for compiling, and it could be extended or
complemented by another tool that generates the Makefiles that would
be necessary if several files must be linked together.
Besides this, there could be a "Get new plug-ins" plug-in or
standalone tool, which would download a list of available plug-ins,
compare with the versions currently installed, and allow the user to
select which ones he/she wants to download, build and install. The
tool would then generate a list of files that are necessary, fetch
them (probably using HTTP, as this is simple to implement) and compile
them. As an added bonus, it could also save the list of files to disk
so that a user who does not have a permanent connection to the
Internet could transfer the list to another computer that is connected
to the Internet or use it as an index to get the files from a CD-ROM.
The only requirement on the plug-in authors would be to organize their
source files in a way that is compatible with gimptool, and maybe
provide a Makefile.in or something similar, so that the final Makefile
can be generated easily.
> If plug-in authors want their plug-in to be binary distributed, they should
> have the possibility to put up binary packages to the new registry as well.
> I do not think we should try to create a new binary package format however.
> Let's see what the future brings. Eventually distros will converge to one
> format anyway.
Maybe. But the binary packages will have to be organized carefully.
Even if all x86 Linux distributions converge to package format, there
will still be some users who want a plug-in that is compatible with an
old Pentium, while some others will want a binary that is optimized
for their Pentium 4. If we are not careful about that, it could
happen that the author of a plug-in stores a binary optimized for the
Pentium 4 (and not compatible with earlier processors) while others
expect this to run on all x86 platforms.
And it will take time before all distros use a common format and
layout for the file system, so in the meantime it will be necessary to
provide different packages for Debian, RedHat, SuSE and others. And
this is only for Linux. There is also *BSD, Solaris, IRIX, HP-UX,
AIX, MacOS X, ... And Windows, of course.