Bug 426167

Quick unofficial review.  The spec file looks good to me at first blush.  Lint
clean on the spec and srpm.  The rpm has a couple warnings.

shenson@turbosnail ~/Code/rpmbuild/RPMS/noarch$ rpmlint
PyYAML-3.05-1.fc8.noarch.rpm 
PyYAML.noarch: W: spurious-executable-perm
/usr/share/doc/PyYAML-3.05/examples/yaml-highlight/yaml_hl.py
PyYAML.noarch: W: doc-file-dependency
/usr/share/doc/PyYAML-3.05/examples/yaml-highlight/yaml_hl.py /usr/bin/python

Those are examples so I believe the warnings are ok.  Othere than that the
package looks good.

About the above rpmlint complaints:

The issue with executable documentation is that it has dependencies.
(Non-executable documentation can have dependencies as well, as rpm will
extract dependency information from perl files and such).  What you don't want
is for documentation to force a bunch of additional dependencies that the
package wouldn't need at all if it were installed without that documentation.
In this case the only dependency is the Python interpreter, so that's OK, but
if that dependency makes use of modules, then you have to watch out that future
RPM releases don't gain enough Python dependency generation logic to figure
those out.

Another consideration is that if the script is sufficiently useful that you
expect users will want to run it, you should just package it as you would any
other executable: in /usr/bin, instead of hidden under /usr/share/doc.

You should drop the manual dependency on python; rpm figures that out for
itself in the form of the python(abi) dependency.

You also probably want to remove the comment in the %files section as that's
just an instruction to the packager that appears in the specfile template.

Checklist:
* source files match upstream:
   27b69bf6f1452e8f41577646ddfe78f9528a437409927d5d543bc97d75e27a03
   PyYAML-3.05.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly
* rpmlint has acceptable complaints.
X final provides and requires:
   PyYAML = 3.05-1.fc9
  =
   /usr/bin/python
X   python >= 2.3
   python(abi) = 2.5

* %check is not present; no test suite upstream.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* 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.

(In reply to comment #2)
> About the above rpmlint complaints:
> 
> The issue with executable documentation is that it has dependencies.
> (Non-executable documentation can have dependencies as well, as rpm will
> extract dependency information from perl files and such).  What you don't want
> is for documentation to force a bunch of additional dependencies that the
> package wouldn't need at all if it were installed without that documentation.
> In this case the only dependency is the Python interpreter, so that's OK, but
> if that dependency makes use of modules, then you have to watch out that future
> RPM releases don't gain enough Python dependency generation logic to figure
> those out.
> 
> Another consideration is that if the script is sufficiently useful that you
> expect users will want to run it, you should just package it as you would any
> other executable: in /usr/bin, instead of hidden under /usr/share/doc.
> 
> You should drop the manual dependency on python; rpm figures that out for
> itself in the form of the python(abi) dependency.
> 
> You also probably want to remove the comment in the %files section as that's
> just an instruction to the packager that appears in the specfile template.
> 
> Checklist:
> * source files match upstream:
>    27b69bf6f1452e8f41577646ddfe78f9528a437409927d5d543bc97d75e27a03
>    PyYAML-3.05.tar.gz
> * package meets naming and versioning guidelines.
> * specfile is properly named, is cleanly written and uses macros consistently.
> * summary is OK.
> * description is OK.
> * dist tag is present.
> * build root is OK.
> * license field matches the actual license.
> * license is open source-compatible.
> * license text included in package.
> * latest version is being packaged.
> * BuildRequires are proper.
> * %clean is present.
> * package builds in mock (rawhide, x86_64).
> * package installs properly
> * rpmlint has acceptable complaints.
> X final provides and requires:
>    PyYAML = 3.05-1.fc9
>   =
>    /usr/bin/python
> X   python >= 2.3
>    python(abi) = 2.5
> 
> * %check is not present; no test suite upstream.
> * owns the directories it creates.
> * doesn't own any directories it shouldn't.
> * no duplicates in %files.
> * file permissions are appropriate.
> * 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.
> 

Thanks Jason,

I have set the example to be non-executable, now the package is rpmlint clean. 
I also removed the explicit python dependency and removed the extra comment.

New spec and srpm:

http://csee.wvu.edu/~johnny/fedora/PyYAML.spec
http://csee.wvu.edu/~johnny/fedora/PyYAML-3.05-2.fc8.src.rpm

Cool; looks good to me.

APPROVED

Seems we're missing some procedure here.  First you'll need to set up your
Fedora account and then apply for sponsorship so I can click the appropriate
buttons, and then once that's done you'll need to do a proper CVS request.

Everything is detailed here: http://fedoraproject.org/wiki/PackageMaintainers/Join

For now I'll unset fedora-cvs and then you can set it again when you're ready.

I have my Fedora account set up.  I have pending requests for the cvsextras and
fedorabugs groups, the folks on #fedora-devel seemed to think that's all I need.
 If not, let me know what you need to get this through.

(The docs located at
http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored doesn't have
any details)

New Package CVS Request
=======================
Package Name: PyYAML
Short Description: YAML is a data serialization format designed for human
readability and interaction with scripting languages.  PyYAML is a YAML parser
and emitter for Python.
Owners: jeckersb
Branches: F-7 F-8
InitialCC: 
Cvsextras Commits: yes

short description is too long ive used "YAML parser and emitter for Python"

CVS Done

It looks like this has been built for rawhide and F8.  Did you intend to build
for F7 as well?

(In reply to comment #9)
> It looks like this has been built for rawhide and F8.  Did you intend to build
> for F7 as well?

I just went ahead and build it for F7 too.

http://koji.fedoraproject.org/koji/buildinfo?buildID=31361

Any reason this can't be closed now?

I guess not, although the builds for the release branches are still in testing.

Package Change Request
======================
Package Name: PyYAML
New Branches: F-9 EL-4 EL-5
Owners: jeckersb

Ignore F-9 branch on previous request, I was having a CVS idiot moment.

Please create EL-4 and EL-5 still:


Package Change Request
======================
Package Name: PyYAML
New Branches: EL-4 EL-5
Owners: jeckersb

CVS Done