On 3/27/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > On Tue, 27 Mar 2007 14:42:36 +0200, MJ Ray <[EMAIL PROTECTED]> wrote: > > We already have ESP-GhostScript, so I think we should use GhostScript > > (GNU-Ghostscript was already using that) and artofcode-Ghostscript > > with a possible AFPL-Ghostscript if that ever releases again (I'm > > confused about the plan for it). > > > It's the artofcode GPL-version that has the name 'Ghostscript', not the > GNU-version, so we have to rename all of the recipes and the best thing > would probably be to have no version use just 'Ghostscript'. But I was > thinking, to make the versions easier to group, perhaps when listing, > wouldn't it be better to have the type/version as a suffix instead of > prefix, and by that those will be listed side by side? > > > Second-best is to rename the GNU one to GNU-GhostScript, call the > > ex-AFPL one artofcode-Ghostscript and blacklist GhostScript as > > ambiguous. Maybe we could even include a 'don't use this, use one of > > these' recipe or would that break stuff? > > > > GPL-GhostScript would be ambiguous (which I think may be artofcode's > > intention) and could apply to most of these competing versions so I > > wouldn't use that name for any of them. > > > Yes, that was the reason about my comment about it beeing real confusing, > so I agree on not having any GPL-version.
Ok, so let me see if I got this straight: There are currently three variants of Ghostscript: * ESP-Ghostscript * GNU-Ghostscript * Artofcode-Ghostscript As far as I understand, these are mostly interchangeable (eg, for using with Latex) except that some CUPS stuff requires ESP-Ghostscript specifically. So, I agree, let's drop the unprefixed name Ghostscript from packages and recipes as it is too ambiguous. We could have it in the compatibility list file of the Scripts package, so that when the variant is not relevant, a Dependencies file can specify Ghostscript and use any of them. (This makes me think that when a recipe/package is not found to fulfill a missing dependency, then the compatiblity list should be looked for alternatives. Don't know if this is already implemented.) -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
