Bug 467260 - (mingw32-filesystem) Review Request: mingw32-filesystem - MinGW base filesystem and environment
Review Request: mingw32-filesystem - MinGW base filesystem and environment
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks: mingw32-binutils mingw32-opensc 1016258
  Show dependency treegraph
 
Reported: 2008-10-16 11:42 EDT by Richard W.M. Jones
Modified: 2013-10-07 15:04 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-30 05:56:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2008-10-16 11:42:53 EDT
Spec URL: http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=918e9f907e958fdbc2016dcc5e36bf4099800bd7;path=/filesystem/
SRPM URL: http://www.annexia.org/tmp/mingw/fedora-9/src/SRPMS/mingw32-filesystem-30-1.fc9.src.rpm
Description: MinGW base filesystem and environment

This is the base component which sets up the filesystem
and environment used by all Fedora MinGW packages.  The
filesystem layout is explained in the packaging guidelines:

http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout

Note that there is no upstream for this package, since it's
something which is maintained and evolved by the Fedora MinGW
SIG ourselves.
Comment 1 Richard W.M. Jones 2008-10-16 11:48:14 EDT
Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=884352
Comment 2 Richard W.M. Jones 2008-10-16 11:49:57 EDT
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
Comment 3 Jason Tibbitts 2008-10-17 15:02:08 EDT
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.
Comment 4 Daniel Berrange 2008-10-17 16:11:31 EDT
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
Comment 5 Richard W.M. Jones 2008-10-17 18:40:37 EDT
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.
Comment 6 Jason Tibbitts 2008-10-27 13:40:07 EDT
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.
Comment 7 Richard W.M. Jones 2008-10-27 14:07:58 EDT
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@redhat.com> - 31-1
- Update the spec file with explanation of the 'Provides: mingw32(...)'
  lines for Windows system DLLs.
Comment 8 Jason Tibbitts 2008-10-28 16:30:57 EDT
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.
Comment 9 Richard W.M. Jones 2008-10-29 07:07:32 EDT
(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@redhat.com> - 33-1
- Remove mingw32.{sh,csh} which are unused.

* Mon Oct 27 2008 Richard Jones <rjones@redhat.com> - 32-1
- Add mingw32-configure script.
Comment 10 Jason Tibbitts 2008-10-29 11:51:11 EDT
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.
Comment 11 Richard W.M. Jones 2008-10-29 12:13:57 EDT
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
Comment 12 Kevin Fenzi 2008-10-29 17:27:24 EDT
cvs done.
Comment 13 Richard W.M. Jones 2008-10-30 05:56:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.