Re: limits for package name and version (MBF alert: ... .deb filenames)
On Tue, 26 Apr 2011, Adam Borowski wrote:
> Telling someone "the bug is in a version I pulled from the VCS but didn't
> bother noting down which version it was" is not very useful.
Now you're being silly.
All you need is the proper date and time to use as a version (for
ordering), and a proper debian/changelog entry:
* New upstream source (git://blah, commit "blah: did something",
[#12030a47ebafdcd]).
I.e. the best current practice. How surprising. Now you either tell
upstream when you checked out his tree (and he can locate the commit by
date/time), or look the hash in debian/changelog and tell him that, and
he might be able to locate the commit even on rebased trees.
Kindly recall we need to limit version string lenght a _LOT_ and will be
doing that shortly one way or the other. $(git describe) is out right
there: it cannot be trusted to fit unless you're just using it to get a tag
with a known to be short pattern, which is not what this is about.
And you certainly should not waste 32 chars for the entire hash since it
is unordered and you need space before it for ordering, and space after
it for all the other stuff we tack at the end, so even that is out.
> > If your upstream is pulling such tricks then you cannot use this type of
> > version *with or without* the hash, because it will not be ordered
> > properly. You would have to use a date/timestamp.
>
> Eh? It is exactly why the hash is there!
No, it isn't. The *FULL* hash is there to identify a commit in that
repository to the VCS. It is certainly not there to identify a release to
human beings or distro packaging systems.
And since the hash is NOT fit for such a job in the first place, you have to
supplement it with ordering for it to become meaningful for release
identification ("which one is newer?"), and we don't have space for all that
stuff in the version string.
Also, it IS worth reminding all that git-describe output has *NO* forward
uniqueness guarantees: for that it would have to always use the full hash,
and even that could break should we be forced to drop sha1 for something
longer.
It also cannot be used [safely] to locate commits that were rebased (and
neither can the hash). So, again, you're down to the full hash, and even
that is not good enough by itself [it is not future-proof when a rebase is
not impossible].
> No matter how many commits were done at a particular date, and whether the
> commit was cherry-picked, rebased or tossed around in other ways, a hash
> will let you tell which exactly version it is.
At one point in time, which is not relevant anymore (a rebase happened), and
the object the hash used to point to might have been lost (garbage
collection).
You're either supposed to not rebase anything that is ever made public, or
to identify a commit by its title when it is unique enough, otherwise by
(author, date, title).
--
"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
Reply to: