Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Mon, 17 Nov 2014, Ron wrote:
> > Anything that doesn't store the full debian version (be it a git tag or a
> > filename) will have a colision risk. Consider a package that has versions
> > 1:2.3.5-1 and 5:2.3.5-1.
>
> Right, that was one of the first cases I mentioned. When you upload
> 5:2.3.5-1, dak will reject it exactly because they will collide. :)
Yes, you're right. Our archive is braindead re. epochs since basically day
one, and blocking colisions in dak was deemeed the lesser evil when compared
to the fallout of fixing the archive filenames.
> fwiw, I don't consider that a compelling reason alone to not include
> the epoch in tags - but you appear to have just confirmed that not
> many people know this, even when it's explicitly mentioned in a
> thread they just replied to! So I think *that* is probably worthy
> of a mention if we do recommend including the epoch in tags :)
Ah, sorry about that...
> > > If the answer is instead something like "I want automated tools to be
> > > able to assume they can perfectly reverse the mangling and assume some
> > > semantic meaning to the text in the tag", then we're into Broken By
> > > Design territory and we really need to look more closely at *exactly*
> >
> > Well, we can have a perfect, reversible transformation between the debian
> > version namespace and the debian git-tag version namespace, where "debian"
> > means "a vendor that uses dpkg and the deb format".
>
> No. I don't believe you can.
>
> Mangle this version in a way that's legal to git: "0:1.2:3..4-1~~2..3.lock"
True. Getting git to accept ".." and a ".lock" suffix in a tag.. urk.
Point taken. Yeah, that'd call for %-encoding or something equivalent, and
those always require also the definition of a canonical form.
> Yes, it's a corner case you've probably never seen, but the troublesome
> parts of that are all legal debian versions.
Yes, just like 1:1.2.3-4 versus 5:1.2.3-4, that dak rejects because the
Debian archive doesn't preserve epochs in its storage layer (filenames).
One interesting detail is that at least apt _DOES_ restore the epoch
information in the deb filenames (it uses URL-like %-encoding, though, so
":" becomes "%3a").
I'd say we should get the epoch-in-tags detail documented in DEP-14.
And the archive restriction re. epochs really should have been documented in
debian policy. It is not even in the developer's reference... but this is
offtopic for this thread.
> > > Henrique, would you care to elaborate on your definition of "safer"?
> >
> > Sure. I consider safer a design that loses no information when translating
> > between the debian version namespace and debian version git-tag namespace,
> > because you won't have permanent colisions among debian versions that differ
> > only on the epoch.
>
> Ok, I can agree with that definition, but as I showed above, this
> plan doesn't satisfy it. You'd need to fully URL encode them or
> similar to have that, and I don't think we should do that.
I agree that a full encoding that requires canonical forms is way too
painful, and that we should not go there.
> You can still semi-meaningfully encode the epoch in a way that
> is a clue to humans, but you *can't* guarantee the version is
> reversible from the necessary mangling.
If we mangle by removing whatever git objects to, yes, it won't be
reversible, at which point we might as well not bother with epochs.
I'd still allow epochs as optional, but that would cause a headache when you
have something like 1:1:4-1 for a debian version... best to recommend that
they be removed when tagging, instead.
So I retract any objections I had against "epoch-less" tagging. But I feel
DEP-14 should document this stuff.
> Are there actually already existing tools that rely on reversing this?
I sure hope there aren't any.
> If there aren't we certainly shouldn't be encouraging creating new ones
> with this flaw in the future.
I agree.
--
"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: