[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: DEP-14: Recommended layout for Git packaging repositories



Ian wrote:
> Guido Günther writes ("Re: RFC: DEP-14: Recommended layout for Git packaging repositories"):
> > On Fri, Nov 14, 2014 at 03:44:35PM +0000, Ian Jackson wrote:
> > > Current practice seem so be to replace both : and ~ with _.  Unless
> > > we
> > 
> > This didn't work well so gbp switched to what Raphael documented years
> > ago (: -> %, ~ -> _).

Can you recall and share some details on what "didn't work so well"
with gbp that this fixed?


> Are there other gitish tools which are still using _ for both ?

The version mangling code in gitpkg converts all constructs that are
illegal for git to _ (and collapses consecutive instances of them to
a single _).

I believe Bernhard explained earlier that git-dpm allows the replacement
character to be configurable (but also offers just a single character
for all replacements).

As I explained in the earlier discussion with Henrique, there are more
things than just : and ~ which are perfectly legal in debian version
strings, but are illegal constructs in git refnames.

To make this even more amusing, somewhere between git 1.7 (on squeeze)
and git 2.1, the rules for what were legal in git refs were tightened
(at least once) to exclude even more things.  I don't know offhand if
this is likely to happen again at any stage.

I'd also be a bit wary of changing existing tools to behave differently
(between different Debian releases that are still supported even) without
a very careful look at what might be affected if previous transformations
were no longer reproduced in the same way, or behaved differently depending
on exactly which chroot you ran them in.


I'd be more interested in a clear statement of what the problems are
with various options, and what we really want to achieve by specifying
anything about this, at this stage.  That would at least give us some
objective measure of what is necessary, and what is actually possible
(and at what cost) to consider.

  Cheers,
  Ron



Reply to: