DEP14 policy for two dots
[ Raphael, apologies for sending twice, had a error in the headers in the prior one ] Not sure exactly where to ask this better than debian-devel, but I am working on an importer for the Ubuntu Server team which parses published versions of source packages in Debian and Ubuntu. I ran into an issue today where there is a published version of src:pcre3 with version '8.30..2'. `man git-check-ref-format` says that reference names "cannot have two consecutive dots .. anywhere." DEP14 specifies appropriate substitutions for : and ~, but it seems like .. should also be accounted for so I can correctly tag historic versions? Thanks, Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Re: DEP14 policy for two dots
On 03.11.2016 [19:37:41 +], Ian Jackson wrote:
> Nish Aravamudan writes ("DEP14 policy for two dots"):
> > [ Raphael, apologies for sending twice, had a error in the headers in
> > the prior one ]
> >
> > Not sure exactly where to ask this better than debian-devel, but I am
> > working on an importer for the Ubuntu Server team which parses published
> > versions of source packages in Debian and Ubuntu. I ran into an issue
> > today where there is a published version of src:pcre3 with version
> > '8.30..2'. `man git-check-ref-format` says that reference names "cannot
> > have two consecutive dots .. anywhere." DEP14 specifies appropriate
> > substitutions for : and ~, but it seems like .. should also be accounted
> > for so I can correctly tag historic versions?
>
> Urk. How exciting. I think we may need a more general escaping
> scheme for these and other weirdnesses.
>
> I have an interest as dgit uses DEP-14 tag escaping. I have CC'd the
> vcs-pkg list.
Thank you, I should have thought of that!
> tl;dr: I think we should insert `#' characters as needed.
Thank you as well for your excellent analysis of the options. I think
the proposal
>Proposed rule:
>
>Insert "#":
> - between each pair of adjacent dots
> - after any trailing dot
> - before any leading dot
>
>Examples:
> 8.30..2 => 8.30.#.2
> 8.30. => 8.30.#
> .42 => #.42
is very reasonable and I assume could be added to DEP14 itself?
Presuming broader agreement, of course. For the purpose of 'ubuntu/'
tagging in our tool, we would adopt the same rule.
Thank,s
Nish
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Re: DEP14 policy for two dots
On 09.11.2016 [21:27:14 +], Ian Jackson wrote:
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> > a reasonable extension.
>
> Attached. FYI I intend to implement this in dgit.
Thank you! We will follow the same in the Ubuntu tooling used by the Server
Team.
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Re: DEP14 policy for two dots
On 09.11.2016 [23:38:30 +], Ian Jackson wrote:
> Nish Aravamudan writes ("Re: DEP14 policy for two dots"):
> > Thank you! We will follow the same in the Ubuntu tooling used by the Server
> > Team.
>
> Great, thanks.
>
> Can I ask you a rather unrelated question ? AIUI you are working on
> importing Ubuntu's history into git. That's great.
Yep, our original use-case was 'Ubuntu merges' where there is some
Ubuntu delta from the Debian package has has to be maintained and
reapplied to new Debian publications.
> Can you confirm what approach you have taken to the representation of
> Debian source packges as git trees ? I would like to encourage you to
> use a representation which is compatible with dgit.
I think we are fairly compatible. The only difference would be the
actual git commits themselves, I think, because we treat Launchpad as
our canonical source of information, while dgit uses the Debian archive
(aiui).
> That is, the git tree object should look exactly like the results of
> `dpkg-source -x', except that the .pc directory which dpkg-source
> creates for `3.0 (quilt)' packages is deleted.
Yes, we use `dpkg-source -x --skip-patches` on an appropriate DSC file
for both Debian and Ubuntu publications. That is the tree we commit with
appropriate parents (as determined by Launchpad's publication history
and the d/changelog file).
> It would probably be nice if the commit history structure of imported
> source packges was a bit like the dgit imports. Or better if it were
> identical, but that's probably too much to ask for because you
> probably do not want to make dgit 2.x a dependency for your project.
I will spend some time next week looking at what dgit imports look like,
but I'm guessing they are not the same currently.
> I encourage you to try out dgit 2.x and see what you think of its
> efforts for some existing source packages. Eg `dgit clone libvirt
> stretch'.
I will do this soon, to compare, thanks!
-Nish
P.S. Totally a plug, but I will be hosting a UOS talk about the importer
and git trees next week:
http://summit.ubuntu.com/uos-1611/meeting/22710/git-based-merge-workflow/
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
