Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#46961 - [mono] libgdiplus as optdepend?

Attached to Project: Arch Linux
Opened by Paul Mulders (justinkb) - Tuesday, 03 November 2015, 22:17 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 18 October 2017, 21:32 GMT
Task Type General Gripe
Category Packages: Extra
Status Assigned
Assigned To Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 4
Private No

Details

Having libgdiplus as strict dependency means we have to pull in all kinds of X/GUI packages, directly and indirectly (via cairo particularly).

On a headless server this could be undesirable. There is plenty of mono software which doesn't use GDI+/System.Drawing at all, so perhaps we can make this optdepend with a note "required for GDI+ drawing functionality".

Of course, packages in the Arch Linux repositories and AUR that rely on mono AND libgdiplus can just explicitly depend on libgdiplus, so there's no problem there.

Looking at libgdiplus's reverse dependencies, I see only mono listed on the package web interface, so perhaps there are currently packages which would have to be changed should this change go through.
This task depends upon

Comment by John M (iefbr14) - Monday, 29 January 2018, 23:28 GMT
I think this is a good idea. I maintain some "regular-size" Intel and some ARM-based (space-constrained) systems that require mono, but none of the libgdiplus dependencies. I've been creating my own mono package without the libgdiplus dependency. Its not a big deal to keep doing this, but it makes sense to build mono with libgdiplus as an optdepends.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 30 January 2018, 15:30 GMT
I'm all pro in favor of listing all the direct dependencies of packages. But I think it would be best if we can come up with a list of these packages that would need to get changed and create a TODO for this.
Comment by John M (iefbr14) - Tuesday, 30 January 2018, 22:59 GMT
Let me preface by stating I'm not a C#/.NET/Mono expert (not even a little bit! :) but I figured there had to be an easy way to determine if any of the Arch packages that require mono ALSO require libgdiplus. So downloaded the packages listed at https://www.archlinux.org/packages/extra/x86_64/mono/ as follows:

avahi-0.7-4-x86_64.pkg.tar.xz
dbus-sharp-0.8.1-1-any.pkg.tar.xz
diffoscope-90-2-x86_64.pkg.tar.xz
graphviz-2.40.1-10-x86_64.pkg.tar.xz
gtk-sharp-2-2.12.45-1-x86_64.pkg.tar.xz
gtk-sharp-3-2.99.3-1-x86_64.pkg.tar.xz
haxe-3.4.4-1-x86_64.pkg.tar.xz
keepass-2.38-1-any.pkg.tar.xz
log4net-2.0.8-1-any.pkg.tar.xz
meson-0.44.0-2-any.pkg.tar.xz
mono-addins-1.3.3-1-x86_64.pkg.tar.xz
nini-1.1.0-5-any.pkg.tar.xz
nuget-2.14-2-any.pkg.tar.xz
openbve-1.5.3.0-1-any.pkg.tar.xz
openra-20171014-1-any.pkg.tar.xz
referenceassemblies-pcl-4.6-1-any.pkg.tar.xz
taglib-sharp-2.1.0.0-3-any.pkg.tar.xz
uwsgi-plugin-mono-2.0.15-9-x86_64.pkg.tar.xz

I extracted each archive and used the monodis tool (comes with mono) with the --assemblyref option (https://linux.die.net/man/1/monodis) to examine each .exe and .dll file to see which used "System.Drawing". I assumed that if the exe/dll uses System.Drawing, it probably requires libgdiplus. I can't say for certain that is 100% valid, but it makes sense to me. :) http://www.mono-project.com/docs/gui/libgdiplus/

This is the list of exe/dll files which use System.Drawing:

./gtk-sharp-2/usr/lib/mono/gac/gtk-dotnet/2.12.0.0__35e10195dab3c99f/gtk-dotnet.dll
./gtk-sharp-2/usr/lib/mono/gtk-sharp-2.0/gtk-dotnet.dll
--
./gtk-sharp-3/usr/lib/mono/gac/gtk-dotnet/3.0.0.0__35e10195dab3c99f/gtk-dotnet.dll
./gtk-sharp-3/usr/lib/mono/gtk-sharp-3.0/gtk-dotnet.dll
--
./keepass/usr/share/keepass/KeePass.exe
--
./openbve/usr/lib/openbve/ObjectBender.exe
./openbve/usr/lib/openbve/CarXmlConvertor.exe
./openbve/usr/lib/openbve/OpenBve.exe
./openbve/usr/lib/openbve/TrainEditor.exe
./openbve/usr/lib/openbve/RouteViewer.exe
./openbve/usr/lib/openbve/ObjectViewer.exe
./openbve/usr/lib/openbve/OpenBveApi.dll
./openbve/usr/lib/openbve/OpenTK.dll
./openbve/usr/share/games/openbve/Data/Plugins/Texture.BmpGifJpegPngTiff.dll
--
./openra/usr/lib/openra/OpenRA.Game.exe
./openra/usr/lib/openra/OpenRA.Platforms.Default.dll
./openra/usr/lib/openra/SharpFont.dll
./openra/usr/lib/openra/mods/common/OpenRA.Mods.Cnc.dll
./openra/usr/lib/openra/mods/common/OpenRA.Mods.Common.dll
./openra/usr/lib/openra/mods/d2k/OpenRA.Mods.D2k.dll

So, assuming my test is valid, that means gtk-sharp-2, gtk-sharp-3, keepass, openbve, and openra require libgdiplus.

Hopefully this information helps at some point!
Comment by Giancarlo Razzolini (grazzolini) - Wednesday, 31 January 2018, 12:39 GMT
@John,

Thanks for looking into it. I can take care of keepass depending on it, since I maintain it. But we would need to create a todo for the remaining ones. I'm waiting for Levente's take on this though.
Comment by Steve M (smmalis37) - Saturday, 31 March 2018, 22:00 GMT
Any update here? I'm one of the people who would be strongly in favor of this change happening, but it seems this issue's been sitting idle for a few months now.
Comment by Giancarlo Razzolini (grazzolini) - Sunday, 01 April 2018, 02:30 GMT
Hi @Steve, I have not tested all this software to see if they work fine with libgdiplus as a dependency directly to them (I don't see why not) instead of mono. I can say that keepass works just fine without it. I'll talk with the devs of those packages and see if they are up to change them and, if so, prepare a todo for this.

Loading...