Remove binaries link to /usr/lib/bin why?

[broucaries]

Hi,

It seems that you removed the move of binaries to /usr/lib and the symlink handling.

By memory I have corrected all the bug of this code quickly.

And they are no mention of this revert on changelog.

Why do you do this ?

Next time could you mention it to changelog ?

We will carry a patch on the debian side for this feature.

Bastien

[magick]

From ChangeLog:

• 2013-04-08 6.8.4-9 Cristy <quetzlzacatenango@image...>
  * Revert 'Move binaries to lib subdirectory and link are created from binary
  package' patch. We're getting too many bug reports.

Search this discussion server for the various problem reports about things that were broken with the symlink patch. We'll revisit the issue when time permits unless you have time to resolve them and resubmit a patch.

[broucaries]

Will send to usual adress some patch:
- one for checking an user error (empty program suffix)
- another to change the bin target name
-the last one moving the binaries

In case of problem you could revert the last one.

BTW i see that you integrated part of my X slip patch. What is the status ?

[magick]

Its a classic problem, contributers come up with a patch that doesn't quite work robustly, particularly for Windows. Since we'll likely be responsible for porting your patch to Windows, could you describe what you are trying to do and why. We can then figure out how to export it so ImageMagick can build under Linux and Windows. Are you simply trying to push anything X into a separate library? If so why, can't you simply add --without X to your configure script command line? This should remove all X11 dependencies and reduce MagickCore bloat.

[anthony]

Or do you need both libraries installed (environment swicthing?)

[broucaries]

@anthony:

We will have three version of imagemagick installed q8 q16 and hdri.

Adding x/nox will go to 6 version and it is a no way.

We wish to have X dependancy considered like a plugin and linked at demand.

The first step I have proposed is to isolate the X dependencies to their own build time libraries (named convenience library http://www.sourceware.org/autobook/auto ... ok_92.html) and after to think about plugin.

Indeed convenience library does not change ABI/API whereas plugin change API/ABI

Bastien

[anthony]

I agree that would be useful. But you need to remember that some thing need X even if they don't need the X server. This can make such a 'optional dependancy' difficult to arrange.

For example X Pixmaps, typically used X window color names. Some font handling also has X dependencies.

Then again many 'delegate' libraries has X window connections, such as Ghostscript.