Re: limits for package name and version (MBF alert: ... .deb filenames)
On Mon, Apr 25, 2011 at 04:07:11PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 26 Apr 2011, Chow Loong Jin wrote:
> > On 26/04/2011 01:50, Gunnar Wolf wrote:
> > > Anyway - Summing up what I'm saying here, tags have a clear meaning: A
> > > point where upstream wants us to base our efforts at, mid-devel-cycle
> > > breakage should be at a minimum. So, instead of basing our packages
> > > off arbitrary commit hashes, why not basing them off tags? I do not
> > > believe it is unreasonable to request upstreams to do some tagging...
> >
> > Because, some times, upstreams don't release at all. See clutter-sharp for a
> > good example of an upstream with not a single tag or release. For the record,
> > I've requested an actual release multiple times before falling back upon
> > packaging a git snapshot.
>
> Then, you use UTC date+time, that's two digits for the best-practice leading
> of "0.", plus 13 digits for YYYYMMDDTHHMM, which is quite precise enough
> most of the time. Add two more for seconds, and it is almost always precise
> enough to identify the head commit in a branch, and you already know which
> branch of which tree because that information must be available and
> up-to-date in debian/copyright. That still leaves enough space for the
> debian revision, security updates, bin-NMUs, NMUs and backporting.
http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1
... four-digit year first, followed by a two-digit numeric month,
followed by a two-digit numeric date, possibly with punctuation between
the components.
digits parts are:
YYYYMMDD or YYYY.MM.DD as I understood this policy.
The aptitude command displays only 10 digits. HHMM may be too much.
(package name up to 30 too)
Although I did not find note "prepending 0. as best practice", it looks
to be a good idea for upstream version.
But, aptitude displays only 10 digits. While about 83% of package have
less than one digit Debian revision, this only leave us with 8 digits.
Even 0.YYYYMMDD becomes 0.YYYYMMDD-1 and 12 digits. No easy solution
here. I guess when YYYYMMDD was proposed, they did not think to put 0.
before them. In this sense, most reasonable solution seems to me
0.YYMMDD
This way, when ever upstream decide to release package with sane
versioning (usually bigger than 1.) within 8 chars and we can continue
without epoch. But this is not documented anywhere.
I guess policy was assuming to use epoch thus recommending to use
YYYYMMDD only. What is the consensus on the best practice. I am abit
confused here.
> And you can supplement the version information with the full commit hash and
> even the repo path in the debian/changelog entry for the upload.
Yes. I agree.
Osamu
Reply to: