On Tue, Feb 20, 2001 at 02:13:28PM +0000, Austin Donnelly wrote:
> On Tuesday, 20 Feb 2001, Robert L Krawitz wrote:
> > This would total four (libgimpprint and associated tests, the
> > plugin, the CUPS driver, and the Ghostscript driver), plus possibly
> > other packages for things like Debian and RPM packaging.
> Well, maybe just 3:
>   libgimpprint
>   print plugin (both of these manually imported to gimp cvs)
>   CPUS + Ghostscript drivers
> Does the Debian maintainer have any comments how he/she would like to
> see it packaged?

The GIMP maintainer?

Currently the GIMP-Print source is made into 5 packages:

Well, I've had a think about this. Due to the way the source is now,
splitting it up won't be too painful. Some things to consider that all
of the parts of the source use lib/libprintut.h. This would have to be
replicated in all of the separate bits. Also, some bits use the same
message catalogue for translations, though this could be changed. In
particular, CUPS genppd will want to use the gimp-print catalogues, but
could use installed versions.

I don't see any problem with making a static library when part of the
GIMP source, but another possibility would be to conditionally build the
shared library. The macro AM_PATH_GIMPPRINT in configure.in will check
for an installed libgimpprint version >= the source version. If this
criterion is not met, then a warning is given, and the included copy is
built instead. This is what happens right now. By adding a check to see
whether it's distributed with the GIMP, you won't need to specify
--disable-libgimpprint to configure, and it will be automatic. If you
wished this could also require it to be linked -static.

>From a Debian packaging point of view, there should be only one package
that provides a file. In this case, the package is currently
libgimpprint 4.1.5-1. By adding a Build-Depends to the GIMP packaging
for libgimpprint-dev, and making library building conditional, there
will only be one copy of libgimpprint around. The latest print plugin is
in the package gimp1.2-print, which diverts the distributed print plugin.
By doing it this way, the two sets of packages can peacefully coexist,
hopefully :)

Does the GIMP configure script allow the calling of sub-configures, or
does the logic in the GIMP-Print configure.in have to be moved into
the root configure.in? If possible, could AC_CONFIG_SUBDIRS be used?
autogen.sh should take care of all the details.

> > I presume you'd want to pick up libgimpprint and the plugin, without
> > the CUPS and Ghostscript drivers.
> Yup.

The cleanest way to do this, I think, would be to simply add a modified
dist target, that will remove src/cups and src/ghost, and also remove
them from src/Makefile.am SUBDIRS. Then the package will work without
them. There will be redundant checks and options in configure.in, but
this will only be a short-term problem if the CUPS driver goes into
the main CUPS source, and ghost into ESP ghostscript.

> > We're working library version skew issues (Roger has architected and
> > done an initial implementation), although there is something to be
> > said for building it statically within the Gimp context.
> Well, one less shared library for users to forget to install properly,
> so yes :)

My own personal view is that all these extra libraries should not be
distributed with the GIMP, but I think that library version problems can
be minimised with AM_PATH_GIMPPRINT. If you like, I can put in a simple
check that we are in the GIMP tree (e.g. test -f ../../gimptool.1.in),
and conditionally compile libgimpprint and statically link print. The
conditional compiling is important, for the packaging reasons mentioned


Roger Leigh ** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
For GPG Public Key: finger [EMAIL PROTECTED] or see public keyservers.
Gimp-developer mailing list

Reply via email to