Yeah, the py* exception needs to be mentioned in the python3 section because so many python2 packages are grandfathered in with that exception. But it could definitely be clearer that we're describing an exception that should not be used for new packages.

I've reworked both of those places you've mentioned. Do they look good now?

A bit better, but it's not that simple.

While the comment in the table explains the history of the "pygtk2" name, some of the other examples don't clearly apply the %parent-%child naming guidelines for Python modules and are ambiguous, IMO.

For example, the gstreamer-python package has two parents. The Python module included in it extends Python with a module to access the GStreamer API (e.g. the Python based app Soundconverter uses it). A valid name for that part of the package would be python-gstreamer, but it also contains a GStreamer plugin that extends GStreamer with the ability to load plugins written in Python. That would justify the gstreamer-python name. In addition to its two different contents it's an old package, so okay if it stays like that. But as an example?

gnome-python2 is a Python module, which extends Python with an API to access GNOME libs. Python is the %parent, and hence the package should be named python-gnome instead. That's what the beginning of the "Addon Packages (python modules)" section claims.

rpm-python extends Python with a Python module to access the RPM API. python-rpm would be the %parent-%child name.

python-lxml seems to be a good example, because it contains a Python module for accessing libxslt and libxml2, and hence the %parent is Python not libxslt/libxml2.

On the contrary, the "Addon Packages (python3 modules)" sections starts with pointing out that "An rpm with a python prefix or '''suffix''' means a python2 rpm", which raises the question how that fits into the %parent-%child guidelines? A suffix "-python" implies that Python is the child and something else is the parent. Aren't Python2 modules always called python-$NAME if following the guidelines?

There are almost two hundred packages named $NAME-python, e.g. vips-python is a Python module. And there are more than a thousand packages named python-$NAME, which could serve as betterexamples in the table.

The new package review request for gstreamer1-python uses gstreamer-python as an example for naming the package. But currently it contains only a Python module that extends Python, so shouldn't it be called python-gstreamer1 instead?

Related note, FPC approved this guideline change last week:

Proposal for language bindings to be named $language-$foo, not $foo-$language (old packages grandfathered but cleanups are welcomed) APPROVED (+1:7, 0:0, -1:0)

I'll have to go through the Naming Guidelines page and update all the entries to make that clear.

Due to grandfathering, we have to keep the information about the old naming scheme around but we need to make it clear that those forms are just for grandfathered packages. not for new packages.

Didn't mean to close this until I've written it up, sorry.

I don't think this was ever written up.

There was, unfortunately, no complete draft provided so I've put something together which I hope at least gets close. I'm sure there are many things I've missed, but I'm happy to fix them up as they're pointed out.

Announcement text:

Clarified the naming guidelines to indicate how language bindings are named: lua-randomdb instead of randomdb-lua. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28General.29