Naming: packages shall not exceed 64 chars long #1439
No reviewers
Labels
No labels
announce
bootstrap
Closed As
accepted
Closed As
duplicate
Closed As
exceptionexpired
Closed As
fixed
Closed As
invalid
Closed As
nothingtodo
Closed As
permanentexception
Closed As
rejected
Closed As
temporaryexception
Closed As
wontfix
cmake
committee
draftneeded
hasdraft
meeting
meson
needinfo
Priority
In Committee
Priority
Needs Review
Priority
Waiting For Reporter
rust
writeup
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
packaging/guidelines!1439
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "64chars"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As some Golang packages exceeded 64 chars length an issue was reported at: https://pagure.io/fedora-infrastructure/issue/12167
Proposed a check in
go2rpmbut I was not able to find official documentation, so I'm opening this PR.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" 😆
Package names SHOULD NOT exceed 64 characters, as Bugzilla cannot handle components with names longer than this.
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
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
fedoraandupdatesrepos. Here are the most egregious examples of unnecessarily verbose naming:(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.
As to that ... the packages with
rust-<crate>+<feature>-develare 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.Ah, that's a good point, yeah.
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.
That ship has left the station indeed. Especially because we need those subpackages for correct dependency resolution 🙃
This I can agree with - but has nothing to do with package names, either.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.