I have no idea why this ticket was never tagged properly.

Discussed this week: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-07-26/fpc.2018-07-26-16.00.txt

• Open floor (geppetto, 16:53:46)
• LINK: https://pagure.io/packaging-committee/issue/703 (tibbs,
  16:54:18)
• ACTION: tibbs will draft a more comprehensive change to say "use
  lowercase" for 703 (geppetto, 17:04:25)

In the five years since this issue was opened, the situation has arguably worsened, and grown to encompass the rules on delimiters as well.

§ General Naming now reads:

Package names SHOULD be in lower case and use dashes in preference to underscores.

Ugh. The vague, it burns!

Case Sensitivity

§ Case Sensitivity reads:

While case sensitivity is not a mandatory requirement, case SHOULD only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you SHOULD use ORBit as the package name, and not orbit. However, if they do not express any preference of case, you SHOULD default to lowercase naming.

Just... a mess of inherent contradictions. When is mixed-case EVER "necessary"? How does an upstream "express a preference of case"? Those throwaway statements are treated as if they're common-sense or obvious things, when they are NOT.

• "FFmpeg" is referred to as such, by its documentation and website. But the commandline tool is "ffmpeg", that's also our package name, and I believe that to be the right call. MOST application and project names are mixed-case, whereas most command and package names are lowercase.

• "Qt" is similarly a project name, the package for its GUI library installs files with names like libQt5Gui.so and a CMake configuration directory named Qt5Gui. But the project name also becomes "qt" in command names like qtdiag and qtcreator, and the subdirectory of the package repo holding the QtGui source is named gui.So again we follow suit, and our package containing Qt5Gui is called qt5-qtbase-gui[-devel].
  
  (For... nebulous reasons.¹ But it's named in all-lowercase, is the point.)

It would almost be more honest if we said, "If the upstream has demonstrated any flexibility regarding capitalization, use lowercase". Except that feels like a sh*tty guideline, even if it would more accurately describe the reality of the issue.

And then there's the canonical example, ORBit. The ORBit2-2.14.19-28.fc36.x86_64 package contains the following files/directories:

$ rpm -ql ORBit2 |grep -i orbit
 /usr/lib64/libORBit-2.so.0
/usr/lib64/libORBit-2.so.0.1.0
/usr/lib64/libORBit-imodule-2.so.0
/usr/lib64/libORBit-imodule-2.so.0.0.0
/usr/lib64/libORBitCosNaming-2.so.0
/usr/lib64/libORBitCosNaming-2.so.0.1.0
/usr/lib64/orbit-2.0
/usr/lib64/orbit-2.0/Everything_module.so
/usr/share/doc/ORBit2
/usr/share/doc/ORBit2/AUTHORS
/usr/share/doc/ORBit2/COPYING
/usr/share/doc/ORBit2/README
/usr/share/doc/ORBit2/TODO

If the package installs a directory /usr/lib64/orbit-2.0, why are we treating it as hung up on the "ORBit" capitalization?

Separators

Broadening the discussion slightly beyond the topic of package-name case, with apologies (but because it relates to that same opening sentence in § General Naming), § Separators basically exists only to more emphatically state the rules on delimiters. (In a way that is both more specific and more useful, but also somewhat contradicts the easy-breezy, loosey-goosey original statement.):

When naming packages for Fedora, the maintainer MUST use the dash - as the delimiter for name parts. The maintainer MUST NOT use an underscore _, a plus +, or a period . as a delimiter.

The rest of the section consists of several paragraphs spent ostensibly walking back its own underscore rule, when it hardly needs to be walked back. Most of the exceptions it grants are for names that were never inconsistent with that section's actual rule to begin with, yet they get treated as if they were.

It's almost like § Separators is walking back not its own, specific rule, but rather the "use dashes in preference to underscores" from § General Naming. When the real problem is with that rule, because (when stated in that form) it's too vague to be useful in the first place.

Nevertheless, § Separators offers, "There are a few exceptions to the no underscore _ rule", when there was never any such rule. The rule from that section is (emphasis mine), "no underscores as delimiters". The underscore is NOT being used as a delimiter in package names like SDL_net-devel-1.2.8-21.fc36.x86_64 or shotcut-langpack-en_GB-22.01.30-1.fc36.noarch. (The latter from RPM Fusion; I wanted to use a Fedora example, but my initial search produced libreoffice-langpack-pt-BR so meh.)

In those examples, the underscore is a component of one of the hyphen-delimited name parts. There was never any contradiction with the "no underscores as delimiters" rule, merely an opportunity to clarify what constitutes a delimiter.

Explicitly presenting guidance on packages of that type is of course useful, but treating them as exceptions to a rule that either (a) never actually existed, or (b) never applied to them, feels wrong. My worry is that, by listing specific (supposed) "exceptions", the guidelines implicitly recognize only those exact cases as permissible under the rule, but no others. Which may preclude packagers applying common sense, when new situations arise where the rule also doesn't apply, other than the exact ones listed in the guidelines.

There are plenty of other potential package names which could have components containing underscores. If not for the existing examples being treated as exceptions, it wouldn't be necessary to list every new one that arises in the guidelines, but right now I fear that will be necessary. It might perhaps be better to instead point out how and why the rule is non-applicable in those cases, and any others like them that may arise in the future. "Give a packager a rule application..." vs. "Teach a packager how to apply a rule...", if you will.

Compat package naming

(Compat package names for packages where the main name ends in a digit, as in the provided example v8_3.13, are the only ones that actually would violate the underscore rule were they not exempted. And whether the period in 3.13 is being used "as a delimiter", in a way that requires exception, is debatable. ...Then again, v8 is a poor example anyway for an entirely unrelated reason: it no longer exists. The v8 package has been dropped from the collection, and is now a dead.package.)

Notes

1. The "qtbase" part comes from the name used by the Qt project for the source repository that contains the default components of their main "Qt" installer for any given version. The question of whether it makes sense to include that in our package naming is a deep rabbithole. The "gui" part, OTOH, actually has nothing whatsoever to do with QtGui itself; in fact, qt5-qtbase-gui contains not only Qt5Gui, but also Qt5Widgets, Qt5OpenGL, Qt5PrintSupport, and other graphical components of the Qt5 distribution.