Re: limits for package name and version (MBF alert: ... .deb filenames)
Ben Hutchings dijo [Sun, Apr 24, 2011 at 04:54:46AM +0100]:
> > 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).
However, the use case described by others in this thread means the
hash is the least significant part of the version - Yes, it lengthens
the version number with no obvious meaning (and the reason for this
thread is precisely limiting the version number length), but it
contains important information in order to get to a given precise
source.
> > 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.
Well, many authors don't ship tarballs but refer to points in their
development history. I am maintaining the Githubredir¹ service, even
though from the beginning I knew it was a limited and probably
near-sighted solution - But yes, I'm limiting its results to tags in
the project history, and I'm expecting the tags to be version numbers
ordered in a sane fashion.
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...
¹ http://githubredir.debian.net/
Reply to: