FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-23-2011, 09:31 AM
Osamu Aoki
 
Default limits for package name and version (MBF alert: ... .deb filenames)

Hi,

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
sequence.

> >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
the situation.

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
following:

=== package name, strings longer than 41 ===
libbusiness-onlinepayment-authorizenet-perl
libbusiness-onlinepayment-transactioncentral-perl
libcgi-application-basic-plugin-bundle-perl
libcgi-application-extra-plugin-bundle-perl
libcgi-application-plugin-anytemplate-perl
libcgi-application-plugin-authentication-perl
libcgi-application-plugin-authorization-perl
libdata-formvalidator-constraints-datetime-perl
libdist-zilla-plugin-changelogfromgit-perl
libdist-zilla-plugin-podspellingtests-perl
libfusioninventory-agent-task-netdiscovery-perl
libfusioninventory-agent-task-ocsdeploy-perl
libfusioninventory-agent-task-snmpquery-perl
libghc6-syb-with-class-instances-text-prof
libglobus-gram-job-manager-callout-error-dev
libglobus-gram-job-manager-callout-error-doc
libjifty-plugin-authentication-bitcard-perl
libjifty-plugin-authentication-facebook-perl
libmoosex-emulate-class-accessor-fast-perl
libmoosex-meta-typeconstraint-forcecoercion-perl
libnet-nationalrail-livedepartureboards-perl
libnet-rendezvous-publish-backend-avahi-perl
libpentaho-reporting-flow-engine-java-openoffice.org
libsyntax-highlight-engine-simple-languages-perl
libtest-http-server-simple-stashwarnings-perl
tryton-modules-account-invoice-line-standalone
tryton-modules-purchase-invoice-line-standalone

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) ===
0.9.15+post20100705+gitb3aa806-2
0.0.0+git20091215.9ec1da8a-2+b2
1.0.0~alpha3~git20090817.r1.349dba6-2
1:2.5.0~alpha4+svn20091009-1+b2
2.1.14+2.6.32.13-201005151340-1
1:2.2cvs20100105-true-dfsg-5+b1
0.9.8+hg20101101.b35a000870cc-1
0.5.10~alpha0+git201005030944-2
1.1.1+ooo-build3.0.0.9+r14588-9
1.2.0~pre3+snap20071004+dfsg-3+b1
3.0~a2+hg1075.9a478044c65c~dfsg1-1

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

Regards,

Osamu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110423093138.GA32395@debian.org">http://lists.debian.org/20110423093138.GA32395@debian.org
 
Old 04-23-2011, 02:06 PM
Ben Hutchings
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Sat, 2011-04-23 at 18:31 +0900, Osamu Aoki wrote:
[...]
> === version, strings longer than 30 (unique ones) ===
> 0.9.15+post20100705+gitb3aa806-2
> 0.0.0+git20091215.9ec1da8a-2+b2
> 1.0.0~alpha3~git20090817.r1.349dba6-2
> 1:2.5.0~alpha4+svn20091009-1+b2
> 2.1.14+2.6.32.13-201005151340-1
> 1:2.2cvs20100105-true-dfsg-5+b1
> 0.9.8+hg20101101.b35a000870cc-1
> 0.5.10~alpha0+git201005030944-2
> 1.1.1+ooo-build3.0.0.9+r14588-9
> 1.2.0~pre3+snap20071004+dfsg-3+b1
> 3.0~a2+hg1075.9a478044c65c~dfsg1-1
>
> Clearly, all of these are able to wrap name within 30 chars.
[...]

I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the information about exactly which commit the
snapshot was can be included in the changelog.

Mercurial revision numbers should not be used either as they are not
consistent between repositories (they really were a stupid idea in a
distributed VCS).

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-23-2011, 02:12 PM
Cyril Brulebois
 
Default limits for package name and version (MBF alert: ... .deb filenames)

Ben Hutchings <ben@decadent.org.uk> (23/04/2011):
> I would like to see policy forbid the use of commit hashes in
> versions. They aren't ordered, and the information about exactly
> which commit the snapshot was can be included in the changelog.

I'll be happy to second any wording you could come up with on that
topic.

KiBi.
 
Old 04-23-2011, 04:37 PM
Henrique de Moraes Holschuh
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Sat, 23 Apr 2011, Cyril Brulebois wrote:
> Ben Hutchings <ben@decadent.org.uk> (23/04/2011):
> > I would like to see policy forbid the use of commit hashes in
> > versions. They aren't ordered, and the information about exactly
> > which commit the snapshot was can be included in the changelog.
>
> I'll be happy to second any wording you could come up with on that
> topic.

Same here. While at it, I also agree with Osamu's proposal.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110423163759.GA22391@khazad-dum.debian.net">http://lists.debian.org/20110423163759.GA22391@khazad-dum.debian.net
 
Old 04-23-2011, 10:52 PM
Dominic Hargreaves
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
> I would like to see policy forbid the use of commit hashes in versions.
> They aren't ordered,

This seems like an odd reason to forbid them; should one also
forbid strings such as 'pre', 'rc', 'lenny', 'squeeze' in version
numbers also because they aren't ordered? Clearly they should only be
used some way towards the right-hand end of the version number, with
appropriate additional ordering hints before them, so that no
false ordering is inferred, but that's a very different matter.

Maybe policy should instead recommend explicitly that such ordering
hints should accompany hashes.

> and the information about exactly which commit the
> snapshot was can be included in the changelog.

True, but since git revisions can actually do much the same thing as
the other typical components of a version string; that is, uniquely
identify the set of changes making up a code archive, the version
string does sound like the best place to put this sort of information.

> Mercurial revision numbers should not be used either as they are not
> consistent between repositories (they really were a stupid idea in a
> distributed VCS).

That does sound like a good reason to discourage use of Mercurial
revision numbers.

Dominic.

--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110423225208.GK4371@urchin.earth.li">http://lists.debian.org/20110423225208.GK4371@urchin.earth.li
 
Old 04-24-2011, 12:31 AM
Adam Borowski
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
> I would like to see policy forbid the use of commit hashes in versions.
> They aren't ordered, and the information about exactly which commit the
> snapshot was can be included in the changelog.

If you use "git describe", removing hashes is a bad idea.

They are needed to identify the version. Version numbers that are not
unique are worthless.

A small portion of the hash is there only to disambiguate potential
branches, ordering is provided by the number of commits:
0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it,
from a branch whose head's hash starts with 1143071.

If I take revision 282 and apply patch X, while you take the same revision
but apply patch Y instead, we both would have the same version number if
hash is not included.

You can then checkout 0.9.0-a0-283-g1143071 in any repository that has my
commits and you'll get that exact version. 0.9.0-a0-283 doesn't give you
that.

> Mercurial revision numbers should not be used either as they are not
> consistent between repositories (they really were a stupid idea in a
> distributed VCS).

For Mercurial, you're probably right.

Just upgrade to git

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
 
Old 04-24-2011, 03:54 AM
Ben Hutchings
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
> On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
> > I would like to see policy forbid the use of commit hashes in versions.
> > They aren't ordered, and the information about exactly which commit the
> > snapshot was can be included in the changelog.
>
> If you use "git describe", removing hashes is a bad idea.
>
> They are needed to identify the version. Version numbers that are not
> unique are worthless.

If versions are not ordered without the inclusion of a commit hash, they
are not ordered *with* it (except by chance).

> A small portion of the hash is there only to disambiguate potential
> branches, ordering is provided by the number of commits:
> 0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it,
> from a branch whose head's hash starts with 1143071.
>
> If I take revision 282 and apply patch X, while you take the same revision
> but apply patch Y instead, we both would have the same version number if
> hash is not included.

But it is not possible for a branch head to be in two different
positions at different times which 'git describe' will distinguish only
by the hash, unless it is rebased.

> You can then checkout 0.9.0-a0-283-g1143071 in any repository that has my
> commits and you'll get that exact version. 0.9.0-a0-283 doesn't give you
> that.
[...]

Last time I looked, policy required upstream source to be provided as
tarballs, not VCS references.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-24-2011, 10:23 AM
Philipp Kern
 
Default limits for package name and version (MBF alert: ... .deb filenames)

["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves <dom@earth.li> wrote:
> On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
>> I would like to see policy forbid the use of commit hashes in versions.
>> They aren't ordered,
> This seems like an odd reason to forbid them; should one also
> forbid strings such as 'pre', 'rc', 'lenny', 'squeeze' in version
> numbers also because they aren't ordered? Clearly they should only be
> used some way towards the right-hand end of the version number, with
> appropriate additional ordering hints before them, so that no
> false ordering is inferred, but that's a very different matter.

Given that wheezy will probably be the last version that's strictly
greater than lenny and squeeze we should switch to Debian version
numbers in the version instead of codenames post-squeeze.
(OTOH it needs to be greater than +squeeze then, so +debXY won't do.)

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnir7uh2.3eh.trash@kelgar.0x539.de">http://lists.debian.org/slrnir7uh2.3eh.trash@kelgar.0x539.de
 
Old 04-24-2011, 11:16 AM
Moritz Mühlenhoff
 
Default limits for package name and version (MBF alert: ... .deb filenames)

["Followup-To:" nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern <trash@philkern.de> schrieb:
> ["Followup-To:" header set to gmane.linux.debian.devel.general.]
> On 2011-04-23, Dominic Hargreaves <dom@earth.li> wrote:
>> On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
>>> I would like to see policy forbid the use of commit hashes in versions.
>>> They aren't ordered,
>> This seems like an odd reason to forbid them; should one also
>> forbid strings such as 'pre', 'rc', 'lenny', 'squeeze' in version
>> numbers also because they aren't ordered? Clearly they should only be
>> used some way towards the right-hand end of the version number, with
>> appropriate additional ordering hints before them, so that no
>> false ordering is inferred, but that's a very different matter.
>
> Given that wheezy will probably be the last version that's strictly
> greater than lenny and squeeze we should switch to Debian version
> numbers in the version instead of codenames post-squeeze.
> (OTOH it needs to be greater than +squeeze then, so +debXY won't do.)

Maybe +rXY as in r for release?

Cheers,
Moritz


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnir81k5.2hd.jmm@inutil.org">http://lists.debian.org/slrnir81k5.2hd.jmm@inutil.org
 
Old 04-24-2011, 11:59 AM
Philipp Kern
 
Default limits for package name and version (MBF alert: ... .deb filenames)

["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2011-04-24, Moritz Mühlenhoff <jmm@inutil.org> wrote:
>> Given that wheezy will probably be the last version that's strictly
>> greater than lenny and squeeze we should switch to Debian version
>> numbers in the version instead of codenames post-squeeze.
>> (OTOH it needs to be greater than +squeeze then, so +debXY won't do.)
> Maybe +rXY as in r for release?

r < s, though. ;-)

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnir845n.3mk.trash@kelgar.0x539.de">http://lists.debian.org/slrnir845n.3mk.trash@kelgar.0x539.de
 

Thread Tools




All times are GMT. The time now is 09:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org