Packaging best practices: binary tools in mingw packages

[Erik van Pienbroek]

Sandro Mani schreef op vr 10-05-2013 om 19:13 [+0200]:
> > 2. Executables which can be used to test the library in question,
> >    for example: gsettings.exe in glib2 and gtk-demo.exe in gtk+
> Do encoders / decoders, and foo2bar converters in general (i.e.
> image_to_j2k.exe, j2k_to_image.exe in openjpeg, or cwebp.exe,
> dwebp.exe in libwebp) enter this category?

Thinking about it makes it hard to draw an exact line... These kind of
executables can be considered as tools to test the library in question,
but at the same time they can also be considered end-user executables.

As the main target audience for our mingw packages are software
developers I don't see any benefits in splitting executables to separate
subpackages. The only case where subpackages really must be used is when
mixing cross-compiled and native binaries.

Software developers are currently already expected to manually collect
all libraries, executables and configuration files themselves when they
want to redistribute their software. By splitting everything over
multiple subpackages we'll make it even more difficult for developers to
find all files which they need to redistribute with their software.

Unless someone can come up with a good reason to use separate
subpackages for executables I would like to continue with what 98% of
all Fedora mingw packages currently already do: bundling all executables
and libraries in the same package.

Regards,

Erik