Bug 248363

Good:
+ Package meets naming guildlines.
+ SPEC file name matches with package base name.
+ License tag says GPL
+ Project home page says LGPL as package license
+ Package contains verbatim copy of the license text
+ SPEC is written in English
+ SPEC file is legible
+ Tar ball matches with upstream
  (md5sum: 40bf06f8081461d8db7d6f4ad5b9f6bd)
+ Package has correct build root
+ BuildRequires are not redundant
+ Local build works fine.
+ package has %defattr an proper file permissions
+ %doc section is small
+ %doc section doesn't affect run time
+ Package contains no duplicates in the %file list
+ Changelog entries are ok.
+ Rpmlint is quite on source package.
+ Rpmlint is quite on binary packages
+ Mock build works fine for Devel (x86_64, i386, ppp64, ppc)

Bad:
- Package needs a Conflict tag, because the current gmp package contains the
mpfr package
- Unnecessary condition on deleting build root in %clean section
- Devel package contains static library

Created attachment 159633 [details]
fixed srpm

Thanks for your review the attached srpm fixes bugs you mentioned.

*** Bug 248354 has been marked as a duplicate of this bug. ***

The mpfr library is released under LGPL2.1, how can saying it is GPL in the
License tag be a "Good" thing?  Of course you can relicense LGPL2.1 code as GPL,
but why would you do that?  License: LGPL would be much better (unless with the
advent of GPL3, LGPL3, LGPL2.5 we start being more explicit and write
GPL2, GPL2+, GPL3, GPL3+, LGPL2, LGPL2+, LGPL2.1, LGPL2.1+, LGPL2.5, LGPL3,
LGPL3+ etc. in License tags.

Also, upstream mpfr releases stable fixes on top of the last release
as a cummulative patch, see http://www.mpfr.org/mpfr-current/patches
It would be good to apply this in the spec file.

Created attachment 159634 [details]
fixed srpm (again)

Thanks Jakub, problems you mention are fixed in this version.

As far as I understand, that package cannot be push in Fedora, unless bug 
#225809 is closed, and libmpfr.a (and mpfr headers) removed from gmp-devel.

There is not a log of traffic in bug #225809. I do not even know if somebody 
is actually maintaining gmp (the version in Fedora is obsolete).

Ivana, what is your plan? Waiting for GMP maintainers to fix their package?

(In reply to comment #6)
> As far as I understand, that package cannot be push in Fedora, unless bug 
> #225809 is closed, and libmpfr.a (and mpfr headers) removed from gmp-devel.

Yes, you right.

> There is not a log of traffic in bug #225809. I do not even know if somebody 
> is actually maintaining gmp (the version in Fedora is obsolete).
> Ivana, what is your plan? Waiting for GMP maintainers to fix their package?

We have to poke the gmp maintainer to do the split, because without the split 
we can't release a separate mpfr library.

(In reply to comment #6)
> As far as I understand, that package cannot be push in Fedora, unless bug 
> #225809 is closed, and libmpfr.a (and mpfr headers) removed from gmp-devel.

Yes, you right.

> There is not a log of traffic in bug #225809. I do not even know if somebody 
> is actually maintaining gmp (the version in Fedora is obsolete).
> Ivana, what is your plan? Waiting for GMP maintainers to fix their package?

We have to poke the gmp maintainer to do the split, because without the split 
we can't release a separate mpfr library.

I have create a suggestion for the gmp package on gmp-4.2.1.

So I thing, you should add a 'Conflict: gmp < 4.2.1' statement into your package.

Hello,
I'm gmp maintainer too so I'd like to update gmp in devel branch too, but I
don't want to remove mpfr files from gmp for long time without existence of the
separate mpfr package. So I plan to do both these changes (update gmp and remove
mpfr files from gmp and add mpfr package) when this review will be approved. 
I will update the conflict flag when I will build the new gmp version. 
Thanks for your comments.

Nice to hear that, Ivana. Do you have a gmp package updated, so that we can 
test it with the mpfr RPM of this bug?

Created attachment 159779 [details]
proposed version of gmp package

Oops good idea - so this is the proposed version of gmp package.

Is there any other problem? Could somebody approved this package review please?
Thanks.

I'm waiting to see a package, where are complaints are fixed.

If I see this package, I will be able to approve your package.

The srpm from comment #5 should have all fixes. Is there any problem with this
package? (perhaps I overlook some comment?)

Soory for my mistake. I have got a look on it and it's looks fine.


*** YOU ARE APPROVED ***

Package Name: mpfr 
Short Description: A C library for multiple-precision floating-point computations
Owners: varekova
Branches:

mpfr-2.2.1-1 package is just built. If there is any problem please create a
separate bug for this component.

Package Change Request
======================
Package Name: mpfr
New Branches: el5
Owners: besser82

Any comments from the Fedora maintainers?