Bug 226196 - Merge Review: perl-Newt (was: newt-perl)
Merge Review: perl-Newt (was: newt-perl)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
:
: 216610 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 15:16 EST by Nobody's working on this, feel free to take it
Modified: 2013-01-09 23:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-18 11:59:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
tibbs: fedora‑review+
tcallawa: fedora‑cvs+


Attachments (Terms of Use)
Suggested specfile patch fixing several issues. (1.81 KB, patch)
2007-02-28 23:27 EST, Jason Tibbitts
no flags Details | Diff

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 15:16:21 EST
Fedora Merge Review: newt-perl

http://cvs.fedora.redhat.com/viewcvs/devel/newt-perl/
Initial Owner: jorton@redhat.com
Comment 1 Jason Tibbitts 2007-02-28 23:26:52 EST
This is just a simple perl module so this should be easy, but this package
seems to be very old and has some interesting things in it.

First off, I'm sure it predates any kind of naming guidelines, but it really
should be called perl-Newt.

rpmlint says:
W: newt-perl incoherent-version-in-changelog 1.08-12 1.08-13
   This just looks like a typo in the last changelog entry.

E: newt-perl zero-length
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Newt/Newt.bs
   The usual Perl specfile template deletes these zero-length droppings with
   find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'

newt-devel is listed twice in BuildRequires.

The license should be "GPL or Artistic", as it is released under the same
terms as Perl.

Nobody I asked could come up with any reason why brp-compress would have to be
run manually in %install.

This is an arch-specific package so generally you need to pass
OPTIMIZE="$RPM_OPT_FLAGS" in %build.  However, if you don't it just uses the
flags that Perl was built with, which are actually OK.

The permissions come out a bit odd, with no owner write bit set.  These are
generally fixed up with a quick chmod.  I also didn't see a reason for the
"fix Newt.so perms" bit as those permissions are set just fine without any
manuall setting.

I'll attach a patch which fixes these issues.  I've left the issue of the name
along, as I'm not sure it's feasible to fix during the F7 test process.

* source files match upstream:
35e78461b24ea7544d030fe71c82b6f633ea56f9bf0fa924ea61e1497863821f  Newt-1.08.tar.gz
X package should be named perl-Newt.
* specfile is properly named, is cleanly written and uses macros consistently.
* build root is OK
  (Actually I'm assuming that the latest packaging committee output will be
  ratified on Thursday; I'll correct this review if it isn't.)
X license field matches the actual license.
* license is open source-compatible.
* license text not included upstream.
* latest version is being packaged.
* BuildRequires are proper (newt-devel is listed twice, but that doesn't
  really hurt)
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks OK.
X rpmlint has valid complaints.
* final provides and requires are sane:
  newt-perl-1.08-13.x86_64.rpm
   Newt.so()(64bit)
   perl(Newt) = 1.8
   newt-perl = 1.08-13
  =
   libnewt.so.0.52()(64bit)
   libnewt.so.0.52(NEWT_0.52)(64bit)
   perl(:MODULE_COMPAT_5.8.8)
   perl(AutoLoader)
   perl(Carp)
   perl(DynaLoader)
   perl(Exporter)
   perl(strict)
   perl(vars)

* %check is not present; test suite is present but interactive.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
X file permissions are a bit odd.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
Comment 2 Jason Tibbitts 2007-02-28 23:27:41 EST
Created attachment 148989 [details]
Suggested specfile patch fixing several issues.
Comment 3 Joe Orton 2007-03-01 04:18:32 EST
Thanks a lot for the review and patch!

I've applied this in -14.  I'm not sure now is a good time to rename the
package, but I've changed crypto-utils (the only package which uses newt-perl)
to use Require/BuildRequire: perl(Newt) to facilitate that.
Comment 4 Jesse Keating 2007-03-01 12:52:55 EST
(In reply to comment #3)
> Thanks a lot for the review and patch!
> 
> I've applied this in -14.  I'm not sure now is a good time to rename the
> package, but I've changed crypto-utils (the only package which uses newt-perl)
> to use Require/BuildRequire: perl(Newt) to facilitate that.
> 

So long as you coordinate with those that need newt-perl the rename now should
be fine.  You'll be doing an obsoletes/provides though right?
Comment 5 Joe Orton 2007-03-06 12:39:15 EST
Jesse: sure; I'm happy to rename this now if it doesn't create more work for
you.  What's the process for a package rename?
Comment 6 Jesse Keating 2007-03-06 12:43:30 EST
(In reply to comment #5)
> Jesse: sure; I'm happy to rename this now if it doesn't create more work for
> you.  What's the process for a package rename?

Depends on if you want to keep history or not.  If you don't, we can import the
new srpm named perl-newt as a new package, and I'll block the old one from the
buildsystem, adding hte new one.  If you want to keep cvs history, this might
get more difficult, but not impossible.
Comment 7 Joe Orton 2007-03-06 12:53:21 EST
I don't care about preserving CVS across the rename, no.  New package at:

~jorton/perl-Newt-1.08-15.src.rpm
Comment 8 Jason Tibbitts 2007-03-08 17:42:23 EST
Any chance you could give a full hostname or put that in a publicly accessible
place?  If it's in your home directory, there's a rather slim chance I can get
to it.
Comment 9 Joe Orton 2007-03-09 09:02:18 EST
Sorry, sure - http://people.redhat.com/jorton/perl-Newt-1.08-15.src.rpm
Comment 10 Jason Tibbitts 2007-03-09 10:39:34 EST
This fails to build for me on rawhide due to the perl-devel split; I added BR:
perl-devel and all is well.

The issues I had are fixed:
  Package name is good.
  License is OK.
  rpmlint is quiet.
  Permissions are fixed.

Looks good to me, other than that perl-devel thing.  I believe that's here to
stay, but the tweak here is easy.

APPROVED
Comment 11 Joe Orton 2007-04-11 08:41:15 EDT
*** Bug 216610 has been marked as a duplicate of this bug. ***
Comment 12 Jason Tibbitts 2007-05-05 21:44:24 EDT
Did this ever get in?
Comment 13 Joe Orton 2007-05-22 11:42:16 EDT
Nope. I guess we need to treat this as a new package?  Here's the SRPM with the
perl-devel BR added:

http://people.redhat.com/jorton/perl-Newt-1.08-16.src.rpm

New Package CVS Request
=======================
Package Name: perl-Newt
Short Description: 
Owners: jorton@redhat.com
Branches: devel
InitialCC: 
Comment 14 Tom "spot" Callaway 2007-05-22 11:52:26 EDT
Not sure if you needed an F-7 branch for this or not, I assumed not.

Also, please remember to fill in the Short Description field on CVS new package
requests.

CVS done.
Comment 15 Jason Tibbitts 2007-06-14 15:12:31 EDT
Can we close this now?
Comment 16 Joe Orton 2007-06-18 11:59:36 EDT
Yes we can!

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