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

[Ron <ron@debian.org>]

Raphael Hertzog wrote:
> On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> > * Raphael Hertzog <hertzog@debian.org> [141111 22:26]:
> 
> > Is using the vendor you use git on a good default for the vendor code
> > you are currently working on? In my experience those two are quite
> > unrelated.
> 
> Do you have a better default to suggest? In any case, having a default
> value is certainly better than not having one and forcing everybody to
> configure it in some ways.
> 
> I try to work in Kali chroots when I do Kali work. It's true that
> it's not always the case but if there were real differences right now I
> would pay more attention or would ensure to have the proper environment.

gitpkg makes it completely trivial to work from the comfort of a real
debian system while preparing releases for other distros or suites,
and to throw builds of that off to a proper clean build chroot.
(you can happily do that for packages from the same tag too)

That was part of why I asked earlier about why you thought this would
be useful and how you thought it would work.


> > Is there a previous case of encoding colons with percent signs?
> 
> This is the current convention used by git-buildpackage and I believe the
> "%" has been picked because it's visually close to ":" (i.e. two dots/two
> circles).

Why include the epoch in tags at all?

The package filenames don't include them, and if you upload two versions
of a package that only vary by epoch then dak will reject it too.

I'm not even sure what p-t would do to you if you tried that on it.


So there's already lots of good reasons why tags without the epoch will
always be unique, and why it's probably even a good sanity check to
help "new contributors" avoid making that mistake when preparing a
new package too.

  Ron