We have discussed this in the past, and I think we didn't want to document an official "limit" just because of bugzilla (no other place imposes a similarly small limit on the length of the package name, AFAIK) ... but we might want to document "BugZilla cannot handle components with names that are >64 characters long, so avoid this" :laughing:

1) Package names SHOULD NOT exceed 64 characters, as Bugzilla cannot handle components with names longer than this.

2) Bugzilla cannot handle components with names longer than 64 characters, so it is advised to keep package names within this limit.

would any of these options be acceptable?

I opened issue https://pagure.io/packaging-committee/issue/1415 when I heard about problems and work was happening elsewhere, the main problem with talking about bugzilla is that it's planned to be replaced.

My guess is that anything in policy should be very general, along the lines of

There are UI and other concerns with long package names, so you should try to keep them under X and have very good reasons to go over Y. Note that you can also use provides to go over those limits.

Y as 64 is somewhat obvious until bugzilla goes away.

Not sure about the best number for X (or Y post bugzilla).

I've been railing against excessively long names ever since the DNF devs decided to go heavy on using libsmartcols for terminal output. When they discuss output formatting, they use package names like "somepackage-0.1.noarch", so of course it seems like a fine idea to make every package name take up as much space as the longest one. But in the real world, especially when packagers are driven by ecosystems that don't penalize long names with things like ugly DNF formatting, packages have names that make columnar formatting a terrible idea (IMHO.)

I whipped up a quick script to survey the package name lengths currently present in the Fedora 43 fedora and updates repos. Here are the most egregious examples of unnecessarily verbose naming:

$ ./dnf_lengths.py --repoid=fedora --repoid=updates
* Longest name: 81 chars
  Top 10:
  [81 chars] rust-plist+enable_unstable_features_that_may_break_with_minor_version_bumps-devel-1.8.0-1.fc43.noarch
  [81 chars] rust-diesel+i-implement-a-third-party-backend-and-opt-into-breaking-changes-devel-2.2.12-2.fc43.noarch
  [77 chars] rust-h3+i-implement-a-third-party-backend-and-opt-into-breaking-changes-devel-0.0.7-2.fc43.noarch
  [76 chars] golang-github-azure-sdk-resourcemanager-resourcegraph-armresourcegraph-devel-0.9.0-3.fc43~bootstrap.noarch
  [71 chars] rust-zerocopy0.7+__internal_use_only_features_that_work_on_stable-devel-0.7.35-3.fc43.noarch
  [71 chars] rust-zerocopy0.6+__internal_use_only_features_that_work_on_stable-devel-0.6.6-7.fc43.noarch
  [70 chars] rust-tikv-jemallocator+override_allocator_on_supported_platforms-devel-0.6.1-1.fc43.noarch
  [70 chars] rust-tikv-jemalloc-sys+override_allocator_on_supported_platforms-devel-0.6.1-1.fc43.noarch
  [69 chars] rust-tikv-jemallocator+unprefixed_malloc_on_supported_platforms-devel-0.6.1-1.fc43.noarch
  [69 chars] rust-tikv-jemalloc-sys+unprefixed_malloc_on_supported_platforms-devel-0.6.1-1.fc43.noarch
* Longest EVR: 63 chars
  Top 10:
  [63 chars] mediawiki-lastmodified-0-0.17.20200627gitbe28231ebcd539fc99775811e5dc6df9064cfa94.fc43.noarch
  [61 chars] mum-hash-devel-0-11.20210318git8e1c0a5699c34bc4952e86dc0509070770f2c625.fc43.x86_64
  [52 chars] python3-citeproc-py-0.8.2-6.s20250328gite295d63.s20250328gitbd8d2db.fc43.noarch
  [51 chars] python3-pyngus-2.3.0^20200513git60b6f10-11.20200513git60b6f10.fc43.noarch
  [43 chars] xorg-x11-drv-armada-0.0.0-16.unstable.20180829git78e7116a5.fc43.x86_64
  [43 chars] golang-github-microsoft-azure-devops-api-devel-v7.1.0-7.20230811gitazuredevops.v7.1.0.fc43.noarch
  [42 chars] yaru-theme-25.10.3-1.20251022git25.10.3.0ubuntu1.fc43.noarch
  [42 chars] yaru-sound-theme-25.10.3-1.20251022git25.10.3.0ubuntu1.fc43.noarch
  [42 chars] yaru-icon-theme-25.10.3-1.20251022git25.10.3.0ubuntu1.fc43.noarch
  [42 chars] yaru-gtksourceview-theme-25.10.3-1.20251022git25.10.3.0ubuntu1.fc43.noarch
* Longest combined 'name+evr': 99 chars
  Top 10:
  [99 chars] golang-github-azure-sdk-resourcemanager-resourcegraph-armresourcegraph-devel-0.9.0-3.fc43~bootstrap.noarch
  [95 chars] rust-diesel+i-implement-a-third-party-backend-and-opt-into-breaking-changes-devel-2.2.12-2.fc43.noarch
  [94 chars] rust-plist+enable_unstable_features_that_may_break_with_minor_version_bumps-devel-1.8.0-1.fc43.noarch
  [91 chars] golang-github-awslabs-aws-multi-module-repository-tools-devel-0-0.7.20221016gitb6ea859.fc41.noarch
  [91 chars] compat-golang-github-haproxytech-config-parser-4-devel-4.0.0~rc2-13.20211213git12e472f.fc41.noarch
  [90 chars] rust-h3+i-implement-a-third-party-backend-and-opt-into-breaking-changes-devel-0.0.7-2.fc43.noarch
  [90 chars] golang-github-microsoft-azure-devops-api-devel-v7.1.0-7.20230811gitazuredevops.v7.1.0.fc43.noarch
  [86 chars] mediawiki-lastmodified-0-0.17.20200627gitbe28231ebcd539fc99775811e5dc6df9064cfa94.fc43.noarch
  [85 chars] rust-zerocopy0.7+__internal_use_only_features_that_work_on_stable-devel-0.7.35-3.fc43.noarch
  [85 chars] golang-github-awslabs-aws-multi-module-repository-tools-0-0.7.20221016gitb6ea859.fc41.x86_64

(SERIOUSLY? "rust-plist+enable_unstable_features_that_may_break_with_minor_version_bumps"? "rust-zerocopy0.7+__internal_use_only_features_that_work_on_stable-devel"? And who's putting full git SHAs into package version numbers, instead of abbreviated short tags?)

@ferdnyc this PR is about source package names (because bugzilla has a hard 64-char limit for component names), not package names in general.

SERIOUSLY?

As to that ... the packages with rust-<crate>+<feature>-devel are sadly unavoidable, those come from project metadata and using a different name would break RPM dependency generators. Don't blame us, blame upstream projects for using ridiculous feature flag names.

@ferdnyc this PR is about source package names (because bugzilla has a hard 64-char limit for component names), not package names in general.

Ah, that's a good point, yeah.

SERIOUSLY?

As to that ... the packages with rust-<crate>+<feature>-devel are sadly unavoidable, those come from project metadata and using a different name would break RPM dependency generators. Don't blame us, blame upstream projects for using ridiculous feature flag names.

That's fair, and I am conscious of that. As I said in the beginning, "in the real world, especially when packagers are driven by ecosystems that don't penalize long names with things like ugly DNF formatting..." I do get that it's coming from upstream. (I don't necessarily agree with the practice of dumping every rust feature flag into a package name, because it explodes both the length and the NUMBER of packages we have to deal with, but that train has sailed.)

The full git SHAs, though, those are just totally unnecessary.

(I don't necessarily agree with the practice of dumping every rust feature flag into a package name, because it explodes both the length and the NUMBER of packages we have to deal with, but that train has sailed.)

That ship has left the station indeed. Especially because we need those subpackages for correct dependency resolution 🙃

The full git SHAs, though, those are just totally unnecessary.

This I can agree with - but has nothing to do with package names, either.