On Thu, 14 Dec 2000, Sven Neumann <sven@xxxxxxxx> wrote: > Lourens Veen <jsr@xxxxxx> 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 binary packages. 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. -Raphael
