On Wed, 2 Mar 2011, Laurențiu Păncescu wrote: >> On 3/2/11 16:10 , Bob Friesenhahn wrote: >> It seems unlikely that Debian can afford to displace the existing 8-bit >> package since it would break existing dependencies. A parallel >> installable GraphicsMagick Q16 package (with renamed shared libraries >> and headers path) seems like the best path forward. Unfortunately, the >> GraphicsMagick build does not currently support alternate names for the >> shared libraries and headers path. > > Is it a lot of work to implement this? I can volunteer some help, if the > Debian maintainer would go along and generate two binary packages. I think > most (all?) binary-based Linux distributions only include 8-bit > GraphicsMagick, and it's a pity: the difference in quality is quite large.
This is no no longer a problem. I don't know when this was implemented but reading the GraphicsMagick manual I came across this option in configure: --with-modules Image coders and process modules are built as loadable modules which are installed under the directory [prefix]/lib/GraphicsMagick-X.X.X/modules-QN (where 'N' equals 8, 16, or 32 depending on the quantum depth) in the subdirectories 'coders' and 'filters' respectively. The modules build option is only available in conjunction with --enable-shared. If --enable-shared is not also specified, then support for building modules is disabled. Note that if --enable-shared is specified, the module loader is active (allowing extending an installed GraphicsMagick by simply copying a module into place) but GraphicsMagick itself is not built using modules. I may be wrong but does this mean that it is now possible to have multiple Magic++ with different quantum values. This should solve the problems of updating. Carnë -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
