Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Sun, 16 Nov 2014, Ron wrote:
> On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
> > On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> > > On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > > > What exactly is your use case you feel this is essential for?
> > > >
> > > > I think this discussion is in danger of going round in circles.
> > > > I'm going to leave it here and let Raphael get on with it.
> > >
> > > I understand Ron's logic and there's certainly value in questioning the
> > > need for something. But this is always a question of cost/value.
> > >
> > > Even if we don't have an immediate need for this property, the problem
> > > is that we can't always envision all the ways people will want to use
> > > the repositories (isn't that what you were trying to tell me about
> > > how upstream can use git?) and I'm pretty sure that dropping the epoch
> > > will be annoying to someone at some point. And the cost of not dropping
> > > the epoch is not very high.
...
> If the answer to that is simply "it's relatively harmless, has minimal
> cost, some things already do it, and it may be a useful visual cue to
> human users, and that's all", then that's a perfectly good reason.
Agreed. But there is a strong technical reason, too, on top of some
technical advantages.
So let me state the strong technical reason (which should at least be
documented in DEP-14, because this _is_ something people often gloss over):
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.
> 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".
In that case, a debian version tag really could have one valid semantic
meaning: one can derive the debian version from the tag, and also the
opposite.
What one cannot do is try to use either the debian version tag or the debian
version to infer anything about the upstream version/versio tags. We agree
on this.
This assumes that DEP-14 will mandate exactly how debian version tags are
formed, and that tools that require DEP-14 semanthics to work correctly will
be upfront about that.
> what it is that people want to do and/or assume, and we probably need
> to look at less fragile solutions that really do satisfy that need.
Trying to handle colisions due to missing epoch information in the git tag
is far more fragile, IMO.
Any tool that needs the full debian version information would either need it
in the tag in a known format, or it would have to parse debian/changelog,
which requires fetching the correct blob from git, and parsing it using
dpkg-parsechangelog. This is *not* fun to implement correctly, especially
when you don't want to mess with the work tree.
> > I fully agree. Please, lets just keep the epoch which is the safer design
> > choice anyway, and get done with it.
>
> 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.
> They still aren't guaranteed to be so even with this convention,
> because there's no hard guarantee that everyone or everything will
> use them. And even if they did, I still don't think you've covered
> every combination of things that are illegal in a git refname which
> might need to be mangled here.
I'd expect tools that make use of DEP-14 strongly recommended/mandatory
definitions to require DEP-14-compliant repositories. I don't think there
is any other sane way to deal with this, other than "don't write such a
tool".
This doesn't mean the tool should not be configurable to try its best in
non-DEP-14 mode, nor does it mean the tool shouldn't try to protect the user
and have sanity checks in place.
If we don't mandate anything in DEP-14, this point is moot, of course. But
IMO we should at least document the debian version tag colision risk when
epochs are not present in the git tags.
> The question of "should we recommend people include epochs in their tag
> names" is entirely separate to the question of "how should tools
> determine the version of a package at a particular ref in the repo".
Sort of. If we recommend an exact format (doesn't have to be a single one),
tools can depend on it as long as they list that clearly as a prerequisite.
--
"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: