limits for package name and version (MBF alert: ... .deb filenames)
- To: Steve McIntyre <email@example.com>
- Cc: Henrique de Moraes Holschuh <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
- Subject: limits for package name and version (MBF alert: ... .deb filenames)
- From: Osamu Aoki <email@example.com>
- Date: Sat, 23 Apr 2011 18:31:38 +0900
- Message-id: <[🔎] 20110423093138.GA32395@debian.org>
- In-reply-to: <20110331124823.GC18130@einval.com>
- References: <20110325141706.GB5152@einval.com> <20110325155235.GA22099@gnu.kitenet.net> <20110325160115.GB23761@einval.com> <20110325162854.GA23012@gnu.kitenet.net> <20110325220948.GD13627@einval.com> <20110326075614.GA29673@rivendell.home.ouaza.com> <20110330105139.GG7527@einval.com> <20110330125449.GA28191@khazad-dum.debian.net> <20110331124823.GC18130@einval.com>
In order to manage package file name length below 90 and to have sane
screen for package management, may I suggest to recommend some limits
(for lintian check etc.):
* package name string should be less than 40 characters.
* version name string should be less than 30 characters.
(security updates etc. excluded)
Older part of maint-guide text recommend to use 20 or less for package
name for last 10 years or so. This may be too short for the modern system
but it is good to have some commonly agreed limits as recommendation.
I will be bumping limit numbers in maint-guide to these.
See below for my rationale with the statistics.
On Thu, Mar 31, 2011 at 01:48:23PM +0100, Steve McIntyre wrote:
> On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote:
> >Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...).
Why UTF-8? We should keep it within ASCII so any system can display all
package file name. In ASCII range, UTF-8 and ASCII are the same byte
> >We really need to curb the long name insanity in the head. And might as
> >well do it in a way that does not hinder our ability to get data where it
> >is needed, i.e. keep it under 100 chars.
> I'm pushing for a little less than that, then the Joliet problems go
> away. We get an absolute maximum of 103 (Unicode) chars there, so I'm
> going to push for a max of 90 for normal uploads. That allows for
> small amounts of growth for security updates etc.
> >There really is no excuse for such long deb names. If a naming convention
> >"requires" it, fix the buggy naming convention.
90 is good upper limit but how do we enforce this.
Since this comes from both package name and version strings, let's see
Here first number is the length of sting, the second number is number of
such package, and the last number is the cumulative %.
(Data: sid, kfreebsd-amd64)
=== stat for package name string length ===
11 1947 36.9% --- mode
14 1717 54.7% --- 50% median
23 611 91.0% --- 90%
32 89 99.0% --- 99%
41 12 99.9% --- 99.9%
52 1 100.0%
Clearly, 20 char is becoming too short for 17% of packages
=== stat for version string length ===
7 8257 53.2% --- 50% median& mode
12 976 90.1% --- 90%
20 73 99.0% --- 99%
30 3 99.9% --- 99.9%
37 6 100.0%
=== stat for filename string length ===
35 1546 43.4% --- mode
37 1363 53.0% --- 50% median
48 569 91.3% --- 90%
58 61 99.0% --- 99%
67 11 99.9% --- 99.9%
76 1 100.0%
Even if we limit the package name to 40 and version string to 30, there
are not much issue. There is no real impact to the archive as the
=== package name, strings longer than 41 ===
All of these are able to wrap name within 40 chars.
(At least less than 50. only one package exceeds it.)
=== version, strings longer than 30 (unique ones) ===
Clearly, all of these are able to wrap name within 30 chars.
I mean there is no reason to have more than 10 uploads a day, timestamp
is best to be limitted less than 11 chars. Hush can be shortened as
needed. So it is very easy to keep this within 30 chars.
With these for normal upload, we can meet
package(40) + "_" + version(30) + "_kfreebsd-amd64.deb" => 90 characters