#774 Reword "Addon Packages" a bit
Closed: fixed a year ago Opened a year ago by churchyard.


If a new package is considered an "addon" package that enhances...
The new package...

I think this applies to new and old packages alike. This was already confusing to a co-worker. I've been asked whether I can change it. Hence I propose to change it to:

If a package or subpackage is considered...
The addon package...

The original email exchange where the question arose was on an internal mailing list. I've copied it here to provide a bit more context.

On 06/14/2018 04:59 AM, Petr Viktorin wrote:

On 06/13/18 21:49, John Dennis wrote:

I could not find the answer this question in the following
documents (did I just miss it?):

https://fedoraproject.org/wiki/Packaging:Python https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#.2Fusr.2Fbin.2Fpython


The question relates to packages that include support for different
languages, typically one subpackage per language. Usually the
language subpackage is named %{name}-python or %{name}-perl. The
implication is the subpackage is is an obvious subpackage of the
package because they the names share a common leading name.

But we've adopted new Python naming guidelines that make explicit
the interpreter version in the package name, e.g. python2-%{name}
or python3-%{name). (Yes I realize this is for "python packages"
whose whole purpose is to package a Python module/package/app).

Question: How is the interpreter version supposed to be handled for
packages that are not primarily Python but rather include some
Python support in a subpackage?

Which is correct? %{name]-python2 or python2-%{name}.

I ask because one of my packages had traditionally built a
subpackage called %{name}-python. Then someone went in as part of
the python 3 transition effort and changed the subpackage from
%{name}-python to python2-{name} via the
%{?python_provide:%python_provide python2-%{name}} macro and added
an Obsoletes on the old %{name}-python subpackage. Is this

Is it OK for subpackages not to start with the name of the main

The guidelines for this case are at: https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Addon_Packages

Thank you Petr, yes that clarifies and is the answer I was looking for.
I did in fact read that section but I interpreted it differently. I wonder if it would help to reword it or add another sentence to clarify. Here is what it says:

"If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora package without being useful on its own ..."

In my case it's a subpackage so the definition of "new package that enhances or adds new functionality to an existing Fedora package". makes it sound like someone has created a new independent package meant to work with an existing package which is not the same thing as an existing package that generates subpackages (those subpackages are children of the parent main package).

I can see in retrospect what the original wording was meant to convey but there is an opportunity to interpret it differently.


When the addon package is a language binding, note that the language itself is always the parent. Thus, a lua binding for the
"randomdb" database would be lua-randomdb, not randomdb-lua. Also
note that some packages may have grandfathered names using the
opposite ordering.

There are some exceptions to this general addon package naming policy, and they are noted below. [...]

So, python2-%{name} would be preferred here. But, the guidelines are
living documents, and if an exception makes sense it's not hard to
get it approved. Do you have a specific package in mind?

I agree that this has always been somewhat confusing. Certainly just removing the "new" seems obvious, since while we know we can't really apply guidelines retroactively without herculean effort, we shouldn't actually write the guidelines as if they don't apply to anything but new packages.

Still, was this the only change we're talking about here?

Metadata Update from @tibbs:
- Issue tagged with: hasdraft, meeting

a year ago

OK, I'm just going to remove the 'new'. If that wasn't the only change you were talking about then please reopen this.

Metadata Update from @tibbs:
- Issue untagged with: hasdraft, meeting
- Issue assigned to tibbs
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.