Packaging best practices: binary tools in mingw packages

Sandro Mani manisandro at gmail.com
Fri May 10 17:13:38 UTC 2013


On 10.05.2013 17:03, Erik van Pienbroek wrote:
> Sandro Mani schreef op vr 10-05-2013 om 16:15 [+0200]:
>
>> It would be nice to standardize the practice, I think there are two
>> issues to discuss:
>> 1. When should exes be shipped?
>> 2. Should they be shipped in the main package, or in a subpackage (i.e.
>> -tools)?
> I think we've got multiple kind of executables:
> 1. Helper executables which are required by the library in question
>     to operate, for example: gspawn-win32-helper.exe in glib2
> 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?
> 3. Native executables which generate other files, for example: moc-qt5
>     in qt5-qtbase and i686-w64-mingw32-pkg-config in mingw-pkg-config
> 4. Cross-compiled executables which generate other files, for example
>     glib-genmarshal.exe in glib2
Do executables such as libpng-config.exe also enter this category?
> 5. End-user executables, for example pidgin.exe and firefox.exe
>
I guess one should clarify the distinction between groups 2, 4 and 5 
better. One possible scenario for including foo2bar converters is that 
(though probably a bad choice) some user may have his application not 
link to the library, but call the foo2bar.exe executable via system() or 
subprocess.Popen. Group 5 would for sure include anything that is a GUI 
application, but drawing the line for command-line applications is less 
easy IMO.

Best,
Sandro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/mingw/attachments/20130510/cdd64299/attachment.html>


More information about the mingw mailing list