Bug#904608: Support specifying upstream VCS location in debian/control
Hi!
On Wed, 2018-07-25 at 18:20:52 -0700, Jonathan Nieder wrote:
> Sean Whitton wrote:
> > On Wed 25 Jul 2018 at 05:14PM +0100, Iain Lane wrote:
> >> Some tools, like git-buildpackage, can support merging an upstream's
> >> version history into Debian packaging repositories. This enables more
> >> rich usage of (D)VCS when packaging - for example `git blame' works
> >> properly.
> >>
> >> Currently there's no canonical place to specify where upstream's VCS is
> >> located so people have to set this up manually themselves. If there were
> >> such a place, it would be possible for tools like `gbp clone' to
> >> configure the VCS to know about the upstream history when checking out a
> >> packaging repository.
>
> I like this use case. Thanks for bringing it up.
>
> > In fact, there is: the Repository field in debian/upstream/metadata.[1]
>
> Neat!
>
> I would have expected to find this information in debian/copyright. The
> Source field there sometimes names an upstream VCS but isn't required to
> do so; I'd be in favor of some tightening of the requirements in
> copyright-format based on how packages in the archive have been using
> the field (for example, encouraging a list of lines each of which has
> the same format as Vcs-* fields).
I've mentioned this before, and while I appreciate some of the good
properties that a structured format such as YAML provides, using it
for any metadata that could be of potential use by low-level package
tooling (such as dpkg-dev), means this information would not be usable
there as I'd really not like to impose a depedency on YAML modules and
shared libraries or similar.
So, from my PoV, it should end up in a deb822 formatted file.
> >> The request here is to ask whether this would be suitable for
> >> debian/control, along the lines of the Vcs-* fields specified in 5.6.26
> >> and the Homepage field in 5.6.23.
>
> My feeling is that it doesn't belong in debian/control.
> The debian/control file is the source for control fields that appear
> in the binary package, Packages file, and Sources file. If I
> understand correctly, the primary consumers of this field would
> already have a copy of the source (via Vcs-Git) so they can get the
> information from other files in the debian/ directory; they don't need
> to get it from the Sources file.
I think it could be argued that both debian/control and debian/copyright
might be appropriate candidates. Because both have some precedent
(Homepace, Source/Upstream-*). I also agree that a free form field would
not be good enough, and that a more structured field should be used
instead, similar to our Vcs-<type> ones.
> With that in mind, Sean's suggestion of using debian/upstream/metadata[1]
> sounds good to me. Would it work well for you?
From dpkg-dev PoV, that would pretty much mean the information is
unreacheable.
> >> If so, I'd be happy to propose wording for policy. I'm not set on any
> >> particular name, so please feel free to weigh in on that if you'd like.
> >
> > Even if we did want to add this to d/control files, we would want to see
> > it already used in d/control files in the archive before documenting
> > that in Policy.
>
> On this subject more generally, I think there's a bit of a
> chicken-and-egg problem. If we want new fields in the Packages or
> Sources file, it does make sense to coordinate a little with potential
> consumers, and it's not obvious to me where the right place to start
> that is (dpkg@packages.debian.org? a DEP? something else?). So I
> understand why people ask policy team.
>
> For the future, I'd like to have good advice to offer for this kind of
> case, even if that advice is as simple as "ask dpkg@packages.debian.org"
> or "ask ftp-master", say.
I think it depends, but yeah involving potential consumers would be
important. In some cases trying to get consensus on debian-devel might
also work (ahem :). Or bringing it up in policy and discussing there.
We did this for example for the nocheck build option.
In any case I don't mind dpkg being the entry point for this kind of
queries, but while in many/most cases I'll try to poke holes at the
proposals, with naming, location, purpose, etc, it must not be the
exclusive right of the dpkg maintainer to decide on this, and any
other relevant party should get involved and have a say.
Thanks,
Guillem
Reply to: