https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Addon_Packages
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 https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines 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 correct? Is it OK for subpackages not to start with the name of the main package? The guidelines for this case are at: https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Addon_Packages
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 https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines 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 correct? Is it OK for subpackages not to start with the name of the main package?
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
https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines
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 correct?
Is it OK for subpackages not to start with the name of the main package?
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.
Specifically: 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?
Specifically:
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. [...]
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
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)
Login to comment on this ticket.