Menu
▾
▴
5 Attachments
#4571 ghostscript-9.18-1
closed-duplicate
nobody
5
2016-02-16
2015-11-17
No
This is an update of ghostscript version 9.16 to version 9.18, released October 5. Verion 9.17 was never released.
Because there is no maintainer named in the package, I took up the challenge to provide this update.
Secondly, I have changed the configuration from a "monolithic" executable, to one that depends on a dynamic library (libgs.dylib). This is done by running "make so;make soinstall" instead of "make;make install".
The dynamic library is useful for other packages that would like to use the API contained in it to link against.
In this latest version, openjpeg is supported, but it relies on openjpeg version 2, instead of version 1 that is released with Fink. Therefore, I made the package compile the internal version of openjpeg. Compiling of all other "built-in" packages is avoided ... Fink's shlibs are used instead.
I split off ghostscript-shlib and ghostscript-dev packages, which contain the ghostscript library (and API) and include files respectively.
The same holds for ghostscript-nox, ghostscript-nox-shlibs, and ghostscript-nox-dev.
Lastly, because there is currently no maintainer, I gladly volunteer to become the maintainer of this package.
Built with "fink -m build ghostscript. Attached are the .info and .patch files, plus the outputs of "dpkg -L ghostscript", "dpkg -L ghostscript-shlibs", "dpkg -L ghostscript-dev". The outputs for the -nox versions are the same.
Sorry, I forgot to change the revision to "1". Changed in the attachment.
I haven't had a chance to try this out yet, but I have a suggestion. You might as well number the -shlibs package -- ghostscript9-shlibs, in preparation for the future.
OK. That is a good suggestion. That should also make it easier to upgrade or downgrade.
I think it is then best to name the packages "ghostscript9", "ghostscript9-dev" and "ghostscript9-shlibs" and add a "Provides: ghostscript" in the first one.
Attached are the updated ghostscript9.info and ghostscript9.patch files.
We often don't number the package containing user-executable programs, since the numbering for library version is most important for building against a package. In the case of user executables, it's most often the case that automatically updating to a newer version (same name) which uses a newer version of the libraries (different name) is fine.
(I probably should have done that with hdf5*-bin, come to think of it, and I probably will for hdf5.10).
And I recommend -not- using Provides: ghostscript, because Provides: is not intended to operate in the same namespace as real packages. People who already have "ghostscript" installed won't automatically update to ghostscript9, because a Provides effectively has version 0-0, so anything with a version is newer. We had a gigantic mess dealing with ghostscript in the past because of this.
So, I'd recommend the following for this package:
ghostscript, ghostscript9-shlibs, ghostscript9-dev
OK. Understood. I'll work on that a bit later. Thanks!
I did as you suggested.
No more "Provides"
Packages are named: ghostscript, ghostscript9-shlibs, ghostscript9-dev
* Alternative packages: ghostscript-nox, ghostscript9-nox-shlibs, ghostscript9-nox-dev
Attached are the (again) updated ghostscript.info and ghostscript.patch, revision 9.18-1
Looks ok to me. If nobody raises an objection in the next few hours, I'll put this in.
Bug: the variants of the -dev need to Conflicts/Replaces each other, and likewise the -shlibs, since they are the same sets of actual filenames. And that filename overlap leads to...
Having a whole suite (library+executable) with multiple variants can create deadlocks for users. For example, if I install ghostscript-nox, which brings in ghostscript9-nox-shlibs, and then decide I want to switch to the x11-enabled form, I cannot install ghoscript9-shlibs because it cannot displace ghostscript9-nox-shlibs because ghostscript-nox needs it. Varianted -dev are no problem because they get swapped in and out all the time anyway, but a varianted stack of runtime packages can be difficult. And the former "just one varianted package" was not a problem because it was not part of a varianted stack.
One solution is to have different install_name of the runtime .dylib. That way the -shlibs packages do not conflict, and there's no deadlock during swapping. Normal build systems have a --libdir flag to control it, but I know gs isn't a fully normal build system.
The -shlbs (and -dev that match it) should be "9.18" not just "9", since that's how the Shlibs entry says the actual runtime file identifies itself. Ghostscript changes this in every version minor version from what I've seen, so every minor version (that has a different install_name) has to have a different -shlibs package name (by policy to avoid breaking all users' previously-installed packages), not just the major number that seems to make more conceptual sense from looking at other packages.
Thinking more about upgrading, might want to name the file itself ghostscript-9.18.info (including %v) so that when the next version comes along, which requires a new -shlibs packagename (but keeping the old .info to keep the old -shlibs still existing), we can easily keep the different .info side by side.
One common pattern I've seen is to put the -shlibs as the parent package, with the runtime package a splitoff of it. That way it's easier to recognize the reason/differences among the different .info.
I'm not sure that I follow, or agree with Daniel's statement here:
For one, there are many packages that do not identify the version in the name, like libgnugetopt. It installs libgnugetopt-1.3.0.dylib, but this 1.3.0 is not in the name of the package or the info file. Besides, for this ghostscript package the compatibility version is 9.0.0, so it would make sense to just call the package ghostscript9. It will NOT break previously installed packages, as they would link to libgs.9.dylib, which is linked to whatever is the latest version. I concede though that I put that one in the wrong package (-dev) whereas it should be in -shlibs. I'll change that.
The other thing Daniel raised is this:
Yes, it is true that it will now be difficult to swap between ghostscript and ghostscript-nox. I think that happens in other places too. I certainly have encountered things like that. But the solution seems eligant enough: just create another library name, and have no more Conflicts/Replaces between ghostscript-shlibs and ghostscript-nox-shlibs. The Conflicts/Replaces between ghostscript and ghostscript-nox will remain though. I can work on that too.
Lastly:
I'm not so sure that is convenient now, since then we would have both a ghostscript.info for an older version and a ghostscript9.info for a newer. Wouldn't we just want to overwrite ghostscript.info? Besides, it works as it is, except for the few details that I'll fix.
ghostscript.info can be destroyed, at the expense of losing CVS history.
libgnugetopt has never been updated to use a newer libversion of its library and dates from the early days of Fink, so it is a poor example.
The compatibility version is irrelevant. Libraries can change compability version without triggering a new package name.
Our nomenclature is based on the install_name of the llibrary. In this case:
$ otool -D /sw/lib/libgs.9.18.dylib
/sw/lib/libgs.9.18.dylib:
/sw/lib/libgs.9.18.dylib
Some packages set up their builds like the following example (wxwidgets300-osxcocoa-shlibs):
$ ls -l /sw/lib/wxwidgets300-osxcocoa/libwx_baseu-3.0.*.dylib
-rwxr-xr-x 1 root admin 2315820 Sep 17 17:09 /sw/lib/wxwidgets300-osxcocoa/libwx_baseu-3.0.0.2.0.dylib
lrwxr-xr-x 1 root admin 27 Sep 17 17:09 /sw/lib/wxwidgets300-osxcocoa/libwx_baseu-3.0.0.dylib -> libwx_baseu-3.0.0.2.0.dylib
But even with the extended library file name, the install_name refers to the less strictly-versioned symlink:
$ otool -D /sw/lib/wxwidgets300-osxcocoa/libwx_baseu-3.0.0.2.0.dylib
/sw/lib/wxwidgets300-osxcocoa/libwx_baseu-3.0.0.2.0.dylib:
/sw/lib/wxwidgets300-osxcocoa/libwx_baseu-3.0.0.dylib
Thus, in this case, "300" is used as the library identifier.
libgs doesn't provide libgs.9.dylib as an install_name. If you call this shared-library "ghostscript9-shlibs", then the next 9.x release, say 9.19, is going to be binary incompatible with it, because its library will have an install_name of libgs.9.19.dylib, and so you'd need to do this stricter versioning anyway.
Only the -shlibs packages shouldn't conflict with each other. The executable and -dev packages are free to do so, so you needn't worry about making ghostscript and ghostscript-nox coexist.
9.18 was added to Fink
Wasn't the point here to have a non-monolithic gs, but one that builds a shared lib SplitOff? The recently updated Fink ghostscript is still monolithic.
Yes. But that's a matter for a new entry.
I agree with Alexander. When I have time again (I'm a bit busy now), I'll go back to this discussion which will help me a lot preparing a non-monolithic version.
I may wait to do this together with the next upstream release (9.19).