Re: Support specifying upstream VCS location in debian/control

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Support specifying upstream VCS location in debian/control

Jonathan Nieder
Hi,

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).

>> 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.

With that in mind, Sean's suggestion of using debian/upstream/metadata[1]
sounds good to me.  Would it work well for you?

>> 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 ([hidden email]? 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 [hidden email]"
or "ask ftp-master", say.

Thanks,
Jonathan

> [1]  https://wiki.debian.org/UpstreamMetadata

Reply | Threaded
Open this post in threaded view
|

Re: Bug#904608: Support specifying upstream VCS location in debian/control

Sean Whitton
Hello,

On Wed 25 Jul 2018 at 06:20PM -0700, Jonathan Nieder wrote:

> 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).

Yes, I too use the Source field to point to the git repository if that
URL is both accessible in a web browser and cloneable with git without
any modification.

I doubt we have enough consistency in the archive to standardise,
though.

> 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 ([hidden email]? 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 [hidden email]"
> or "ask ftp-master", say.
Indeed, it would be nice to have this.

I think though that the answer might be too complicated to write down.
The consumers of the field is going to be different for each proposed
new field.

It's probably fine for discussions to start here and then we can
reassign the bugs when we figure out who the consumers are.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Support specifying upstream VCS location in debian/control

Iain Lane-8
In reply to this post by Jonathan Nieder
Control: retitle -1 Specify a canonical location for upstream's VCS to be declared

On Wed, Jul 25, 2018 at 06:20:52PM -0700, Jonathan Nieder wrote:

> 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.
>
> With that in mind, Sean's suggestion of using debian/upstream/metadata[1]
> sounds good to me.  Would it work well for you?
Thanks for the feedback. I don't particularly mind where it is - it just
"felt" natural to me to have this alongside the other important
repository: the packaging one. Hopefully my retitling helps.

However, I'm not very keen on the extra work that would be required to
transfer that wiki page into policy as opposed to specifying an extra
field.

Do you agree that policy should recommend such a location and is the
path to this recommendation, in your opinion, a ratification of the
UpstreamMetadata page or something like it?

Cheers,

--
Iain Lane                                  [ [hidden email] ]
Debian Developer                                   [ [hidden email] ]
Ubuntu Developer                                   [ [hidden email] ]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Support specifying upstream VCS location in debian/control

Guillem Jover
In reply to this post by Jonathan Nieder
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 ([hidden email]? 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 [hidden email]"
> 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