I guess we are only supposed to package libraries that are also available as native packages (at least where it makes sense). I can't seem to find a native package. Shouldn't native be packaged first?

native package glibc already contains it, but unfortunately msvcrt do not:-(

GLibC contains the same regular expression functions as exported by this library. However, we can't use GLibC for Win32 targets so that's why I've proposed this package.

The functions exported by this library are required for GtkHTML

(In reply to comment #1)
> I guess we are only supposed to package libraries that are also available as
> native packages (at least where it makes sense). I can't seem to find a native
> package. Shouldn't native be packaged first?  

That's not a hard requirement.  The requirement is only
that what we package is a development tool or library.
We do package other stuff that's not available natively.

(In reply to comment #2)
> native package glibc already contains it, but unfortunately msvcrt do not:-(  

Right -- this is exactly analogous to the situation with
XDR in glibc versus mingw32-portablexdr.

There should be no problem packaging this lib.

Fedora review http://www.ftd4linux.nl/contrib/mingw32-rxspencer-alpha3.8.g4-2.fc11.src.rpm 2009-05-22

Scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1370223

rpmlint output:
$ rpmlint mingw32-rxspencer*
mingw32-rxspencer-static.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/librxspencer.a
mingw32-rxspencer-static.noarch: W: no-documentation
4 packages and 1 specfiles checked; 1 errors, 1 warnings.

As per Packaging/MinGW, these errors can be ignored.

+ OK
! needs attention


+ rpmlint output
+ Package is named according to Fedora MinGW packaging guidelines
+ Specfile name matches the package base name
+ Package follows the Fedora MinGW packaging guidelines
+ License meets guidelines and is acceptable to Fedora
  BSD
+ License matches the actual package license
+ The package contains the license file (COPYRIGHT)
+ Spec file is written in American English
+ Spec file is legible
+ Upstream sources match sources in the srpm
20a95769c0adf98f0f014e0a423a0e32  rxspencer-alpha3.8.g4.tar.gz
20a95769c0adf98f0f014e0a423a0e32  x/rxspencer-alpha3.8.g4.tar.gz

n/a Package builds in mock
n/a ExcludeArch bugs filed
+ BuildRequires list all build dependencies
n/a %find_lang instead of %{_datadir}/locale/*
n/a binary RPM with shared library files must call ldconfig in %post and
%postun
+ Does not use Prefix: /usr
+ Package owns all directories it creates
+ No duplicate files in %files
+ %files has %defattr
+ %clean contains rm -rf $RPM_BUILD_ROOT
+ Consistent use of macros
+ Package must contain code or permissible content
n/a Large documentation files should go in -doc subpackage
+ Files marked %doc should not affect package
n/a Header files should be in -devel
    Fedora MinGW guidelines allow headers in main package
+ Static libraries should be in -static
n/a Packages containing pkgconfig (.pc) files need 'Requires: pkgconfig'
n/a libfoo.so must go in -devel
n/a -devel must require the fully versioned base
n/a Packages should not contain libtool .la files
    Fedora MinGW guidelines allow .la files
n/a Packages containing GUI apps must include %{name}.desktop file
+ Packages must not own files or directories owned by other packages
+ %install begins with rm -rf $RPM_BUILD_ROOT
+ Filenames must be valid UTF-8
! use %global instead of %define

Spec URL: http://www.ftd4linux.nl/contrib/mingw32-rxspencer.spec
SRPM URL:
http://www.ftd4linux.nl/contrib/mingw32-rxspencer-alpha3.8.g4-3.fc11.src.rpm

* Fri May 22 2009 Erik van Pienbroek <epienbro> - alpha3.8.g4-3
- Use %%global instead of %%define

As discussed on the mailing list, I don't know if this review needs to be continued: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-May/001469.html

> Version:        alpha3.8.g4
> Release:        2%{?dist}

I believe this Version-Release tuple does not satisfy naming guidelines. [1] It seems to be an alpha pre-release, and you need to make sure you have a clean upgrade path once it hits final 3.8.

Upstream versioning looks like a mess. What does the "g4" part in there mean?

I think version and release should be something like:
Version:        3.8
Release:        0.2.alpha%{?dist}

When you change anything in the spec file, just update Release to "0.3.alpha%{?dist}". Once there is a final 3.8 release, you can change the Release to "1%{?dist}". This way ensures that every new Version-Release tuple is numerically higher than the previous one.

[1] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages

(In reply to comment #7)
> As discussed on the mailing list, I don't know if this review needs to be
> continued:
> http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-May/001469.html  

As far as I understand, Tor Lillqvist's gripes were:
- same DLL filename for two completely incompatible libraries
- use of "secret sauce" to compile the DLL

You do neither. There's no secret sauce as far as I can see, and librxspencer-0.dll does not clash with any preexisting DLL afaik.

So IMO we can continue.

Anyway, I think it would be good to follow Kalev's comments, even though the project hasn't done a release the last 15 or so years and it's therefore quite unlikely it will anytime soon.

Just found this link on the website of rxspencer explaining the alpha status, http://arglist.com/regex/usenet-spencer-1993-08-07.txt :

 Then there's my new one, which is the regular-expression implementation
 shipping with 4.4BSD.  The good news is that it's completely POSIX.2
 compliant.  The bad news is that it's pretty slow; it's basically an
 alpha release, and I'd really hoped to get at least to a beta before
 4.4 shipped, but that didn't happen.  Eventually there will be a faster
 release, but don't ask me to set a date just yet.

That comment was from back in '93..

I think it's better to drop this package in favor of libgnurx. I'll package it and come up with a new review request ASAP.

Ok, so dropping out as reviewer and closing the review request.