Spec Url: http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML.spec SRPM Url: http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML-1.005-2.src.rpm Description: Glade is a free user interface builder for GTK+ and GNOME. After designing a user interface with glade-2 the layout and configuration are saved in an XML file. libglade is a library which knows how to build and hook up the user interface described in the Glade XML file at application run time.
New version: http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML-1.005-3.src.rpm http://www.perl.me.uk/downloads/modules/md5sums
perl-Gtk2-GladeXML-1.005-3.src.rpm builds in mock for fc4 rpmlint perl-Gtk2-GladeXML-1.005-3.fc4.i386.rpm W: perl-Gtk2-GladeXML devel-file-in-non-devel-package /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/Gtk2/GladeXML/Install/gladexmlperl.h Now the review guidelines say that all header files must be in devel subpackage, but so far I can't find any examples of a contributed perl package that follows this rule. So i'm pretty sure we can ignore this because its a perl package. Both perl-Glib and perl-Gtk2 for example have similar files without a devel package. Good: meets packaging naming guides for perl packages spec name matches licensed GPL and text included in the doc section matches upstream source md5 097ab67c4f0025b74e721ae835a2d554 owns all created directories legible spec check and clean sections look good no shared objects in linker path to worry about I'm not seeing any obvious blockers. But I would like to ask why you are doing find examples -type f -exec chmod -x {} ';' to remove the executable bit on the sample scripts? If you are going to remove the executable bit should you include a short additional readme file in the examples directory tell users they need to run the examples under a call to perl instead of trying to re-enabled the x bit. -jef
(In reply to comment #2) > I'm not seeing any obvious blockers. But I would like to ask why you are doing > find examples -type f -exec chmod -x {} ';' > to remove the executable bit on the sample scripts? If you are going to remove > the executable bit should you include a short additional readme file in the > examples directory tell users they need to run the examples under a call to perl > instead of trying to re-enabled the x bit. This is probably to prevent additional dependencies being added to the package by find_requires as a result of executeable example code. Another way around that would be to use a custom find_requires script that runs the default script and then filters out any bogus dependencies.
(In reply to comment #3) > Another way around > that would be to use a custom find_requires script that runs the default script > and then filters out any bogus dependencies. Sounds like that cure is worse than the disease. I'm not sure how important leaving the example scripts executable is. Here's the requirements that get sucked in if the scripts are left executable perl(constant) perl(Data::Dumper) perl(File::Spec) perl(Gtk2::Gdk::Keysyms) perl(Gtk2::GladeXML) perl(Gtk2::SimpleList) /usr/bin/perl All of these are provided by packages which are required already, perl and perl-Gtk2. So in this case we aren't really filtering anything significant. I think as a compromise it might be most appropriate to add a README.FEDORA file or similar which points out which additional packages are needed to run the examples and that the non executable examples can be run as arguments to the perl command instead of as stand-alone executables. example FEDORA.README To use the the examples in this directory you may need to install these additional packages if they are not already present on your system: <list of additional packages here, though in this case the list is empty> The examples are shipped non-executable. To run the examples call them as arguments to the perl command. For example: >cd /usr/share/doc/perl-Gtk2-GladeXML-1.005/examples >perl progress.pl -jef
(In reply to comment #4) > (In reply to comment #3) > > Another way around > > that would be to use a custom find_requires script that runs the default script > > and then filters out any bogus dependencies. > > Sounds like that cure is worse than the disease. I'm not sure how important > leaving the example scripts executable is. Here's the requirements that get > sucked in if the scripts are left executable > > perl(constant) > perl(Data::Dumper) > perl(File::Spec) > perl(Gtk2::Gdk::Keysyms) > perl(Gtk2::GladeXML) > perl(Gtk2::SimpleList) > /usr/bin/perl > > All of these are provided by packages which are required already, perl and > perl-Gtk2. So in this case we aren't really filtering anything significant. In that case I don't see any point in turning off the executable bits of the example files at all.
Okay coming back to this sprog dependancy, two small specfile corrections I think should be made before I do final review approval: 1) remove "find examples -type f -exec chmod -x {} ';'" As per discussion in comment 3 - comment 5, this isn't really needed, the examples do not pull in any additional dependancies not already required or assumed. 2) use %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS" similar problem as discussed in bug 166252 Just give me one last spec file to review this one will be in the bag i think. -jef
Cheers, will do as soon as I can.
Added OPTIMIZE="$RPM_OPT_FLAGS" and removed "find examples -type f -exec chmod -x {} ';'", then rebuilt New version: http://www.perl.me.uk/downloads/modules/ perl-Gtk2-GladeXML-1.005-4.src.rpm http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML.spec http://www.perl.me.uk/downloads/modules/md5sums
perl-Gtk2-GladeXML-1.005-4.src.rpm builds in mock for fc4 and devel OPTMIZE looks good demo executables work on fc4 Approved.
(In reply to comment #6) > 1) remove "find examples -type f -exec chmod -x {} ';'" > As per discussion in comment 3 - comment 5, this isn't really needed, the > examples do not pull in any additional dependancies not already required or assumed. I was the one who asked Gavin to add the above line to the specfile (see https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00567.html). Some of of us have been following the policy of disabling the executable bit bit for every documentation file. The main reason is that it avoids pulling new requirments as explained by Paul in comment #2 (rpm still pulls requirements from perl modules though). The other reason is more of personnal taste - we don't like to see runnable files shipped as documentation. /jpo PS - The package is still approved.
> I was the one who asked Gavin to add the above line to the specfile (see > https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00567.html). > > Some of of us have been following the policy of disabling the executable bit > bit for every documentation file. The main reason is that it avoids pulling > new requirments as explained by Paul in comment #2 (rpm still pulls requirements > from perl modules though). The other reason is more of personnal taste - we > don't like to see runnable files shipped as documentation. in this case.. and im sure its very much a special case..there are no extra deps pulled in. But I'm also not seeing a check and removal of executable bits documented in the living wiki documentation of the review process. Sorry I missed the discussion thread in the extras list where concensous was reached. Can you get this incorporated as a reviewer SHOULD check or maybe a blurb about non-executable examples in the packaging guidelines for "Documentation." I don't have a strong opinion either way, so I just went with my gut. But now i know...and knowing is half the battle. Yo Joe! I still think it might be a good idea to have boilerplate fedora readme saying that the examples have been delibrately made un-executable since its a change from upstream source behavior. -jef
(In reply to comment #11) > ... But I'm also not seeing a check and removal of executable bits > documented in the living wiki documentation of the review process. Sorry I > missed the discussion thread in the extras list where concensous was reached. > Can you get this incorporated as a reviewer SHOULD check or maybe a blurb about > non-executable examples in the packaging guidelines for "Documentation." I > don't have a strong opinion either way, so I just went with my gut. But now i > know...and knowing is half the battle. Yo Joe! I don't think it has been written in a Wiki page. It is one those lessons learned the hard way, i.e, after being bitten by things like: https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00793.html ;) Note: We have been using this convention since Fedora.us days (at least some of the perl packagers). /jpo
Built and available in development since September 2005, please CLOSE as NEXTRELEASE.