The following code aims to find the package with a maximum chars lenght in the tree: MAX="0" ; for PACKAGE in $( eix --only-names ) ; do LENGHT="${#PACKAGE}" ; test "${LENGHT}" -gt "${MAX}" && MAX="${LENGHT}" ; done ; echo "${MAX}" The result is gnome-extra/gnome-shell-extension-control-blur-effect-on-lock-screen that has 68 chars, so it is really hard make a stabilization commit message for packages like this. I'd suggest to increase the value if you think that remove the rule is not possible.
s/80/69
The exact check is this: > # accept 69 overall or unit+50, in case of very long package names > elif len(summary.strip()) > 69 and len(summary.split(":", 1)[-1]) > 50: > problems.append("summary line is too long (max 69 characters)") Even in the case of a very long package name, you should still have 50 characters to work with. Are you seeing some different behavior? That might be a bug. Do you require more than 50 characters to summarize the changes?
I opened the bug because Dakon says the same and I remember that I had this problem. However commit 703fb2c1ae9874719fb1e151da143de64738ea89 can be an example.
These limits are defined in GLEP 66, and it doesn't say anything about the length of the package name. The rule there simply is "The summary line must not exceed 69 characters". Which isn't very practical for packages with long names. @mgorny: Where does the number 69 originate from? Some statistics for the length of package names (${CATEGORY}/${PN}): Mean: 20.3 10-percentile: 14 Median: 19 90-percentile: 28 95-percentile: 31 98-percentile: 34 99-percentile: 37 Shortest package names: dev-go/qr, dev-ml/re, net-fs/mc, x11-wm/i3 (9 chars) Longest package name: gnome-extra/gnome-shell-extension-control-blur-effect-on-lock-screen (68 chars) Alternatively, we could introduce a maximum length for package names. :)
That commit has this summary: > sys-kernel/vanilla-sources: Automated version bump to {4.4.281,4.9.280,4.14.244,4.19.204,5.4.141,5.10.59,5.13.11} - remove old. I count 128 characters, 100 of which are after the colon. The start of the message could be shortened, but even then we are looking at 60 characters just for the version list by itself. I think the version list would need to be dropped, or the limits imposed by repoman (and GLEP 66) would need to be ignored. Alternatively, you could split this into multiple commits, probably one for each version.
Another possible work around would be to move the version list from the commit summary to the message body in cases where the list is very long. Something like this: > sys-kernel/vanilla-sources: automated version bump > > Added: > 4.4.281 > 4.9.280 > 4.14.244 > 4.19.204 > 5.4.141 > 5.10.59 > 5.13.11 > > Removed: > 1.2.3 > 1.2.4 > 1.2.5
(In reply to Ulrich Müller from comment #4) > These limits are defined in GLEP 66, and it doesn't say anything about the > length of the package name. The rule there simply is "The summary line must > not exceed 69 characters". Which isn't very practical for packages with long > names. Yep, we made the repoman check more lenient outside the policy. I don't think the GLEP really needs to concern itself with finding super exact rule that works for everyone — we just set a good recommendation and assume that there are good cases not to follow this policy to the word. Of course, you could discuss if having super long package names is really a good idea in the first place. If anything, it's pain for users to type them if they have to. > @mgorny: Where does the number 69 originate from? It's a de-facto standard in the git world. I'm not sure if it affects git itself but e.g. the vim-syntax marks the summary line when it exceeds 69 chars, and GitHub cuts the summary at 69 chars.
I feel like the current repoman behavior is a reasonable compromise that prevents people from writing overly verbose messages in the summary. If people feel the need to bypass it, they can run repoman commit --force, or commit using git directly. I would vote for WONTFIX on this.
It works for me now, but it hasn't in the past, i.e. the partition check was introduced after I changed my script to not pass the 69 limit. I removed my special hacks and it works with longer descriptions fine just now.
(In reply to Mike Gilbert from comment #5) > Alternatively, you could split this into multiple commits, probably one for > each version. ...and this is exactly what should happen and how most of us do things nowadays.
can't we exclude the package name from the length calculation instead?
(In reply to Fabian Groffen from comment #11) > can't we exclude the package name from the length calculation instead? But we do, see comment #2. I vote for WONTFIX too.
