[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: limits for package name and version (MBF alert: ... .deb filenames)


On Wed, Apr 27, 2011 at 03:11:14PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 26 Apr 2011, Uoti Urpala wrote:
> It is still not a good reason to waste part of a draconian 30 chars of space
> with hash information.

I agree.

Anyway, I think 30 should be the absolute upper limit for policy.  This
should not be used casually as the length for most softwares.  aptitude
only displays 10 characters.  Debian revision part (-1) uses 2.  So if we
want to offer best user experience, 8 should be the top value for most
programs if this is possible.
(Quite frankly, aptitude default of 10 may be too short.)

For me even bzr/git/hg/... seems useless information as a part of
version. My idea for nicer versioning schemes are the following. 

 0~YYMMDD       for any package checked out from VCS on the day
                or for renaming package with brain dead version string
 0~YYMMDD.1     if you need to make second version after your mistake :-)
 0.YYMMDD       for any package checked out from VCS on the day and you
                know upstream will be releasing 1.x soon.

 1.2.10~YYMMDD  for prerelease of version 1.2.10
 1.2.10~rcYMMDD for prerelease of version 1.2.10 (alternative format)
   this last 2 are mostly used in unstable/testing only.  So length is
   less of problem.

+b is nice but +nmu seems redundantly long.  I wish things are simpler

 1.2.10+b1      for binNMU
 1.2.10+n1      for nmu to unstable
 1.2.10+r1      for stable update
 1.2.10+r2      for stable update if r1 existed.
 1.2.10+u1      for derivatives like Ubuntu repackage?
 1.2.10+x1      for derivatives repackage

I also wish NMU versioning for Debian revision become in line with the
above practice.  So suffix rules are the same for native and non-native

For now, I updated maint-guide just based on facts only with milder
wordings without above idea as:


(For now, I am keeping old YYYYMMDD style.)


Reply to: