Bug 467260 (mingw32-filesystem)

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=884352

List of files contained in the package for easy reference:

/etc/profile.d/mingw32.csh
/etc/profile.d/mingw32.sh
/etc/rpm/macros.mingw32
/usr/i686-pc-mingw32
/usr/i686-pc-mingw32/bin
/usr/i686-pc-mingw32/lib
/usr/i686-pc-mingw32/sys-root
/usr/i686-pc-mingw32/sys-root/mingw
/usr/i686-pc-mingw32/sys-root/mingw/bin
/usr/i686-pc-mingw32/sys-root/mingw/include
/usr/i686-pc-mingw32/sys-root/mingw/include/sys
/usr/i686-pc-mingw32/sys-root/mingw/lib
/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig
/usr/i686-pc-mingw32/sys-root/mingw/share
/usr/i686-pc-mingw32/sys-root/mingw/share/aclocal
/usr/i686-pc-mingw32/sys-root/mingw/share/doc
/usr/i686-pc-mingw32/sys-root/mingw/share/info
/usr/i686-pc-mingw32/sys-root/mingw/share/man
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man1
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man2
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man3
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man4
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man5
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man6
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man7
/usr/i686-pc-mingw32/sys-root/mingw/share/man/man8
/usr/i686-pc-mingw32/sys-root/mingw/share/man/manl
/usr/i686-pc-mingw32/sys-root/mingw/share/man/mann
/usr/lib/rpm/mingw32-find-provides.sh
/usr/lib/rpm/mingw32-find-requires.sh
/usr/share/doc/mingw32-filesystem-30
/usr/share/doc/mingw32-filesystem-30/COPYING

And the requires/provides:
$ rpm -q --requires -p mingw32-filesystem-30-1.fc9.noarch.rpm 
/bin/bash  
config(mingw32-filesystem) = 30-1.fc9
rpm  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
setup  

$ rpm -q --provides -p mingw32-filesystem-30-1.fc9.noarch.rpm 
config(mingw32-filesystem) = 30-1.fc9
mingw-filesystem < 26
mingw32(gdi32.dll)  
mingw32(kernel32.dll)  
mingw32(mscoree.dll)  
mingw32(msvcrt.dll)  
mingw32(ole32.dll)  
mingw32(user32.dll)  
mingw32-filesystem = 30-1.fc9

I'm not understanding how this package can possibly provide things like "mingw32(kernel32.dll)" if it only contains directories, a text file and some shell scripts.  The comment says:
  # These are actually provided by Windows itself, or Wine.
but since this package doesn't have any dependency on, say, Wine, I don't understand how having the dependency in this package actually helps anything.  Is there any documentation about this?  The guidelines only say  
  If a package contains binaries which depend on a DLL provided by another 
  package, these dependencies should be expressed in the form:
    mingw32(foo.dll)
but that doesn't actually talk about what should provide these symbols.

Windows DLLs are a complex beast. A DLL actually contains two parts, one used at runtime and one used at link time. Most of the mingw32 packages we're adding will contain both parts (one part lives in 'bin', the other in 'lib), but the core Windows system DLLs are a special case. They can be provided in many different ways, by Windows itself, by Wine, or (partially) by Mingw toolchain. If you want to run the packages, then Wine would provide the actual DLLs, but if you're compiling & linking, the combination of the mingw runtime, w32apis & gcc packages contain the magic parts neccessary for Windows system packages. It might be better if these fake provides were part of 'mingw-runtime' or 'mingw-w32apis', but in the end it doesn't make a whole lot of difference - there's never any package with a true kenrel32.dll involved in mingw32, so some package needs the fake provides regardless

Basically, what Daniel said in comment 4.

I'll explain it in slightly different terms:-

Let's say we build zlib (bug 454416).  When we run our find-requires
script as part of rpmbuild, they will find the list of DLLs which zlib1.dll depends
on.  In the particular case of zlib, it's KERNEL32.dll & msvcrt.dll.  These are in
the "normal" case proprietary, non-free Windows binaries.

So the question arises, how did we build zlib1.dll given that we don't have
these proprietary libraries around?

We built them from the w32api package, which is a Public Domain set of header
files that duplicate the headers found in Windows dev kits, and provide stubs.
As Dan explained, Windows DLLs really come in two parts - the library of functions
itself and a set of stub routines that you link to the caller.  In w32api the stubs are in
%{_mingw32_libdir}/libkernel32.a, which is compiled from public domain source
by our open source gcc/binutils toolchain.[*]

We want to be able to build & install mingw32-zlib without necessarily needing to
install wine.  (And certainly not needing to install Windows!)  There is no requirement
to have wine installed in order to use the mingw toolchain to develop software (ie.
to compile more stuff on top of it), so why require that?

So for expediency, this base package "provides" the "missing" DLLs.  Another way to
do it would be to exclude these proprietary DLLs in our find-requires checking
script - essentially it comes out the same either way.

[*] If it sounds like I'm over-emphasizing the completely free / open source
nature of this, then I am.  People don't believe that this can be built from 100%
Free (as in speech) software, but it is.

Honestly, the last two paragraphs above the footnote were sufficient.  But this needs to get into the actual spec, so that people who ask this question later can look at the package and understand what's going on.

Were the spec commented to add that, I see no reason that I wouldn't approve it.

I hope I've understood your request correctly ...

SRPM: http://www.annexia.org/tmp/mingw32-filesystem-31-1.fc10.src.rpm
Spec: http://www.annexia.org/tmp/mingw32-filesystem.spec

* Mon Oct 27 2008 Richard Jones <rjones> - 31-1
- Update the spec file with explanation of the 'Provides: mingw32(...)'
  lines for Windows system DLLs.

Yes, that's what I was looking for.  Now we have a permanent explanation of why a package with nothing but a few directories and shell scripts would seem to provide the win32 kernel.

Now, down to the review.  rpmlint says:
  mingw32-filesystem.src:38: W: unversioned-explicit-provides mingw32(gdi32.dll)
  mingw32-filesystem.src:39: W: unversioned-explicit-provides 
   mingw32(kernel32.dll)
  mingw32-filesystem.src:40: W: unversioned-explicit-provides mingw32(ole32.dll)
  mingw32-filesystem.src:41: W: unversioned-explicit-provides 
   mingw32(mscoree.dll)
  mingw32-filesystem.src:42: W: unversioned-explicit-provides 
   mingw32(msvcrt.dll)
  mingw32-filesystem.src:43: W: unversioned-explicit-provides 
   mingw32(user32.dll)
These should all be adequately covered by the added comment.

  mingw32-filesystem.src: W: strange-permission mingw32-find-provides.sh 0775
  mingw32-filesystem.src: W: strange-permission mingw32-find-requires.sh 0775
No idea why these are group writable in the srpm, but it doesn't really matter.

  mingw32-filesystem.noarch: E: only-non-binary-in-usr-lib
Indeed, there are no binaries, just directories; that's quite OK for a filesystem package.

  mingw32-filesystem.noarch: W: non-standard-dir-in-usr i686-pc-mingw32
Obviously that's intended and accepted by the guidelines; it would be nice to get rpmlint to accept this.  Could you file a ticket?

Otherwise, I have one remaining question about the two files placed in /etc/profile.d: what would be set here? Is the point to eventually add things to $PATH or set some specific environment variables?  Because it seems a bit odd to add two files there which contain nothing but comments.

(In reply to comment #8)
>   mingw32-filesystem.src: W: strange-permission mingw32-find-provides.sh 0775
>   mingw32-filesystem.src: W: strange-permission mingw32-find-requires.sh 0775
> No idea why these are group writable in the srpm, but it doesn't really matter.

They are installed with the correct permissions anyway.

>   mingw32-filesystem.noarch: W: non-standard-dir-in-usr i686-pc-mingw32
> Obviously that's intended and accepted by the guidelines; it would be nice to
> get rpmlint to accept this.  Could you file a ticket?

Bug 468981.

> Otherwise, I have one remaining question about the two files placed in
> /etc/profile.d: what would be set here? Is the point to eventually add things
> to $PATH or set some specific environment variables?  Because it seems a bit
> odd to add two files there which contain nothing but comments.

Yes, those were intended to store environment variables, but since
we never got around to using them for anything, I have removed them
from the latest version.

SRPM: http://www.annexia.org/tmp/mingw32-filesystem-33-1.fc10.src.rpm
Spec: http://www.annexia.org/tmp/mingw32-filesystem.spec

* Wed Oct 29 2008 Richard Jones <rjones> - 33-1
- Remove mingw32.{sh,csh} which are unused.

* Mon Oct 27 2008 Richard Jones <rjones> - 32-1
- Add mingw32-configure script.

Great.  This new package has added
  mingw32-filesystem.src: W: strange-permission mingw32-configure.sh 0755
which again doesn't matter.  I've no idea what rpmlint has against executable files in srpms.

I don't really see a point in running through my checklist for a package that doesn't really contain anything, so I won't bother.

APPROVED

Please note that I will probably review some of the library packages, but do not feel remotely qualified to review the binutils package that everything seems to depend on.  Sorry about that.

New Package CVS Request
=======================
Package Name: mingw32-filesystem
Short Description: MinGW base filesystem and environment
Owners: rjones berrange
Branches: F-10 EL-5
InitialCC: rjones berrange

cvs done.

devel done: http://koji.fedoraproject.org/koji/taskinfo?taskID=912137

F-10 done: http://koji.fedoraproject.org/koji/taskinfo?taskID=912138

EL-5 uid 603

Thanks for Jason & Kevin's help.