Bug 706705

Taking this one, I'll also sponsor Felipe once this review is done

Full review done:

Good:
- rpmlint checks return:
 rpmlint rpmbuild/SRPMS/libmtag-python-0.3.1-1.fc15.src.rpm rpmbuild/RPMS/x86_64/libmtag-python-*
libmtag-python.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/libmtag.so libmtag.so()(64bit)
3 packages and 0 specfiles checked; 0 errors, 1 warnings.
 These can all be ignored
- package meets packaging guidelines
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file

Needs work:
===========
-package does not meet naming guidelines, python modules should be called
 python-name rather then name-python, see:
 http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29

 So the package (and the specfile) should be named python-libmtag, I realize
 this contradicts what upstream does, but Fedora names all python modules this
 way for consistency

-There is no clear license info available in the upstream source tarbal, please 
 ask upstream (I think that may mean asking yourself :) to add a LICENSE file
 and proper copyright headers to the source files.

-Please include NEWS in the %doc files

-It is ok to include the egginfo file in the Fedora package, see:
 http://fedoraproject.org/wiki/Packaging:Python#Packaging_eggs_and_setuptools_concerns
 But if you consider it not useful to have it is ok to leave it out too

(In reply to comment #1)
> ===========
> -package does not meet naming guidelines, python modules should be called
>  python-name rather then name-python, see:
> 
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29

Error 503 Service Unavailable

>  So the package (and the specfile) should be named python-libmtag, I realize
>  this contradicts what upstream does, but Fedora names all python modules this
>  way for consistency

Are you sure? There are *a lot* of packages this way:

zinnia-python
xapian-bindings-python
vtk-python
vips-python
vigra-python
util-vserver-python
thunarx-pythonx
telepathy-farsight-python
stfl-python
spice-gtk-python

I could go on.

If I go to the cached page I even see these as examples:
 * gstreamer-python
 * gnome-python2
 * rpm-python

> -There is no clear license info available in the upstream source tarbal, please 
>  ask upstream (I think that may mean asking yourself :) to add a LICENSE file
>  and proper copyright headers to the source files.

Copy LGPL v2.1? Ok.

> -Please include NEWS in the %doc files

Ok.

> -It is ok to include the egginfo file in the Fedora package, see:
> 
> http://fedoraproject.org/wiki/Packaging:Python#Packaging_eggs_and_setuptools_concerns
>  But if you consider it not useful to have it is ok to leave it out too

I don't see the point. I'll leave that out.

Please clarify on the naming scheme, it doesn't seem to be strongly enforced.

Hi,

(In reply to comment #2)
> (In reply to comment #1)
> > ===========
> > -package does not meet naming guidelines, python modules should be called
> >  python-name rather then name-python, see:
> > 
> > http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29
> 
> Error 503 Service Unavailable
> 

Works for me, I think you hit a temporary glitch.

> >  So the package (and the specfile) should be named python-libmtag, I realize
> >  this contradicts what upstream does, but Fedora names all python modules this
> >  way for consistency
> 
> Are you sure? There are *a lot* of packages this way:
> 
> zinnia-python
> xapian-bindings-python
> vtk-python
> vips-python
> vigra-python
> util-vserver-python
> thunarx-pythonx
> telepathy-farsight-python
> stfl-python
> spice-gtk-python
> 
> I could go on.

These are packages where the python bindings are build from the same sources tarbal as the main package, so they follow the usual <main-packagename>-<sub-package-name> convention, however these are the exception if you
do: yum list 'python-*' you will find many many more named that wau.

> 
> If I go to the cached page I even see these as examples:
>  * gstreamer-python
>  * gnome-python2
>  * rpm-python
> 
> > -There is no clear license info available in the upstream source tarbal, please 
> >  ask upstream (I think that may mean asking yourself :) to add a LICENSE file
> >  and proper copyright headers to the source files.
> 
> Copy LGPL v2.1? Ok.
> 

Yes include a copy of the LGPL v2.1 and add a standard GPL copyright
header to the single C file please.

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > >  So the package (and the specfile) should be named python-libmtag, I realize
> > >  this contradicts what upstream does, but Fedora names all python modules this
> > >  way for consistency
> > 
> > Are you sure? There are *a lot* of packages this way:
> > 
> > zinnia-python
> > xapian-bindings-python
> > vtk-python
> > vips-python
> > vigra-python
> > util-vserver-python
> > thunarx-pythonx
> > telepathy-farsight-python
> > stfl-python
> > spice-gtk-python
> > 
> > I could go on.
> 
> These are packages where the python bindings are build from the same sources
> tarbal as the main package, so they follow the usual
> <main-packagename>-<sub-package-name> convention, however these are the
> exception if you
> do: yum list 'python-*' you will find many many more named that wau.

Why would that matter? It certainly doesn't make any different to the end-user how the package was created.

What if I put the bindings inside libmtag, as I actually have been thinking on doing, would I be entitled to name the package libmtag-python then? I don't think that makes sense.

Plus, it's actually not the case on xapian-bindings, thunarx-python, and even gstreamer-python (which is actually mentioned as an example) (and probably others).

> > If I go to the cached page I even see these as examples:
> >  * gstreamer-python
> >  * gnome-python2
> >  * rpm-python

My feeling is that this is not a strong requirement, if it was, there should be a bug report to rename packages such as gstreamer-python, and it should be take out of the examples.

And if there is indeed such a rule that in-package bindings can be named $NAME-python, it should be mentioned in the documentation. More likely, these packages have to be renamed as well.

I did not make the naming rules. The ones which you mention which break them may pre-date the naming rules, or the reviewer was not doing a proper job :)

Anyways I'm fine with making an exception here, esp. considering that at a later date the python bindings may move into the main src tarbal. So lets keep the name as libmtag-python. That just leaves the adding of a copyright header + License file to be sorted out and then we're good to go.

I'm not using Fedora any more.