Packaging best practices: binary tools in mingw packages

[Sandro Mani]

On 10.05.2013 19:13, Sandro Mani wrote:
>
> 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
>

To briefly revive this, any suggestions on what guidelines should be 
adopted for command line tools which are potentially end-user tools, but 
may also be useful for applications which wish to call them?

Best,
Sandro

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