Hello Alpinists,
We (at Adélie) have identified a few issues with the Alpine ImageMagick
package:
1) The version of Ghostscript packaged in main/ghostscript is AGPL, not
GPL. I believe it violates the licenses of both packages to link them
together, and yet this is happening.
I highly suggest that Alpine ship Ghostscript 9.06, the last GPL
version, along with Debian's security patches for it. We had to do this
when we were based on Gentoo (see
https://code.foxkit.us/adelie/packages/blob/ebuild/app-text/ghostscript-gpl/ghostscript-gpl-9.06.ebuild
for the ebuild I wrote) because Gentoo's CUPS depends on Ghostscript.
If an APKBUILD for Ghostscript 9.06 is desired, I would be more than
happy to create one.
2) ImageMagick's X11 support is disabled. I would understand that,
allowing one to use ImageMagick without installing X11 libraries, but
ImageMagick is linked against librsvg, which is linked against pango.
As shown on the Alpine package browser[1], pango pulls in libX11 and
libXext, which are ImageMagick's only X11 library dependencies. As
such, no makedepends/checkdepends modifications are technically
necessary to change to --with-x (though libx11-dev and libxext-dev would
be a good idea). Since this adds a lot of functionality and virtually
no binary size difference, we think it'd be a good idea to investigate this.
Best,
--arw
[1]: https://pkgs.alpinelinux.org/package/edge/main/s390x/pango
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
On 03/29/18 10:06, Natanael Copa wrote:
> I would prefer not use an old/abandoned version of ghostscript.> > It looks like you can build imagemagick with --without-libgs and the> pdf.so plugin will execute an external program instead of link directly> to libgs. This means that we can work around the link time license issues.> > I have tested and the pdf.so plugin is built but not linked with libgs.> I have not tested if it actually works though.
I'll investigate this further; I wasn't aware the pdf.so plugin was
built anyway when --without-libgs was passed.
> If we go that route we need to either:> - document the optional dependency for ghostscript> - manually add ghostscript as an explicit dependency> - move pdf.so and gs.so plugins to a separate subpackage> (imagemagick-pdf?) and add ghostscript as dependency for those.
The subpackage might be a good idea. Then the deps are explicit but
only for those that need it.
> We could maybe even separate out the imagemagick pdf and gs plugins> anyways. That way you only get the license problem when you install the> plugin?> >> 2) ImageMagick's X11 support is disabled. I would understand that,>> allowing one to use ImageMagick without installing X11 libraries, but>> ImageMagick is linked against librsvg, which is linked against pango.>> As shown on the Alpine package browser[1], pango pulls in libX11 and>> libXext, which are ImageMagick's only X11 library dependencies. As>> such, no makedepends/checkdepends modifications are technically>> necessary to change to --with-x (though libx11-dev and libxext-dev would>> be a good idea). Since this adds a lot of functionality and virtually>> no binary size difference, we think it'd be a good idea to investigate this.> > Good idea. I will look into that.> > Alternatively we could put the svg.so plugin in a subpackage. Then we> don't pull in the X11 libs til someone explicitly asks for svg support.
I may be in the minority, but I primarily use ImageMagick (the package,
not -libs) for display(1) functionality, so for me I'd like X11 support.
I don't know if the X11 support can be put in an -x11 package or not
because I'm not sure what apps end up linked to libX11 and libXext. I
will look in to that as well.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
On Fri, 23 Mar 2018 03:07:57 -0500
"A. Wilcox" <awilfox@adelielinux.org> wrote:
> Hello Alpinists,> > We (at Adélie) have identified a few issues with the Alpine ImageMagick> package:> > 1) The version of Ghostscript packaged in main/ghostscript is AGPL, not> GPL. I believe it violates the licenses of both packages to link them> together, and yet this is happening.
It looks like Fedora also does this?
https://src.fedoraproject.org/rpms/ImageMagick/blob/master/f/ImageMagick.spec#_177> I highly suggest that Alpine ship Ghostscript 9.06, the last GPL> version, along with Debian's security patches for it. We had to do this> when we were based on Gentoo (see> https://code.foxkit.us/adelie/packages/blob/ebuild/app-text/ghostscript-gpl/ghostscript-gpl-9.06.ebuild> for the ebuild I wrote) because Gentoo's CUPS depends on Ghostscript.> If an APKBUILD for Ghostscript 9.06 is desired, I would be more than> happy to create one.
I would prefer not use an old/abandoned version of ghostscript.
It looks like you can build imagemagick with --without-libgs and the
pdf.so plugin will execute an external program instead of link directly
to libgs. This means that we can work around the link time license issues.
I have tested and the pdf.so plugin is built but not linked with libgs.
I have not tested if it actually works though.
https://opensource.stackexchange.com/questions/4791/should-my-webapp-also-be-agpl-if-i-use-imagemagick-linked-with-ghostscript
If we go that route we need to either:
- document the optional dependency for ghostscript
- manually add ghostscript as an explicit dependency
- move pdf.so and gs.so plugins to a separate subpackage
(imagemagick-pdf?) and add ghostscript as dependency for those.
We could maybe even separate out the imagemagick pdf and gs plugins
anyways. That way you only get the license problem when you install the
plugin?
> 2) ImageMagick's X11 support is disabled. I would understand that,> allowing one to use ImageMagick without installing X11 libraries, but> ImageMagick is linked against librsvg, which is linked against pango.> As shown on the Alpine package browser[1], pango pulls in libX11 and> libXext, which are ImageMagick's only X11 library dependencies. As> such, no makedepends/checkdepends modifications are technically> necessary to change to --with-x (though libx11-dev and libxext-dev would> be a good idea). Since this adds a lot of functionality and virtually> no binary size difference, we think it'd be a good idea to investigate this.
Good idea. I will look into that.
Alternatively we could put the svg.so plugin in a subpackage. Then we
don't pull in the X11 libs til someone explicitly asks for svg support.
> Best,> --arw> > > [1]: https://pkgs.alpinelinux.org/package/edge/main/s390x/pango>
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---