Bug#904608: Support specifying upstream VCS location in debian/control
Sean Whitton writes ("Bug#904608: Support specifying upstream VCS location in
debian/control"):
> No-one needs to do that extra work anytime soon. Policy lags best
> practices. The fact that debian/upstream/metadata is already being used
> to store a URI to the upstream repository for a large number of packages
> counts as standardisation, in Debian Policy terms. You can refer to it
> in tools that you write.
YAML is utterly awful. The spec is gigantic. We should not
perpetuate it.
Ian.
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- 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 (d...@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 d...@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
Bug#904608: Support specifying upstream VCS location in debian/control
control: retitle -1 Include upstream metadata spec in Policy control: tag -1 +moreinfo Hello, On Thu 26 Jul 2018 at 09:21AM +0100, Iain Lane wrote: > 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? No-one needs to do that extra work anytime soon. Policy lags best practices. The fact that debian/upstream/metadata is already being used to store a URI to the upstream repository for a large number of packages counts as standardisation, in Debian Policy terms. You can refer to it in tools that you write. We should eventually move the upstream metadata spec into Policy. I'm retitling the bug, but also tagging it as moreinfo. The moreinfo tag is used to indicate that it is not clear that the bug against debian-policy is actionable. What is currently unclear is whether the upstream metadata spec is sufficiently mature to go into Policy. We need to hear from those involved with that spec that it's sufficiently mature to go into Policy. If it's sufficiently mature, such that all that's needed is writing a patch to Policy, we can remove the moreinfo tag and leave the bug open, awaiting someone driving its inclusion in Policy. If the spec is not ready to go into Policy, then there is no Policy work to be done, and we should close the bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#904608: Support specifying upstream VCS location in debian/control
On Wed, 25 Jul 2018 18:20:52 -0700, Jonathan Nieder wrote: > > 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). Just sharing my experience (pkg-perl again :)): We're tracking upstream VCS (well, just Git) locations since about 4 years. The default is to record them in debian/upstream/metadata. [0] That was based on the simple fact that there was a specification for it (with the Repository: key) and that writing and reading YAML is trivial. A group of packages uses the Source field in debian/copyright, which in my experience is a bit of a pain since parsing out the Git location from a list of URLs in a multiline field is not trivial. Summary: I'm a happy consumer of upstream git locations, I'm all for standardizing, keeping debian/upstream/metadata is easiest for us; if we decide on anything else, be it d/control or d/copyright, then I very much suggest to use a new single unambiguous field for the information. Cheers, gregor [0] And we've built tools around it, as dpt subcommands. -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Beny More: Que Bueno Baila Usted signature.asc Description: Digital Signature
Bug#904608: Support specifying upstream VCS location in debian/control
On Thu, Jul 26, 2018 at 09:05:33AM +0800, Sean Whitton wrote: > control: tag -1 +moreinfo > 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. Thanks Sean. This is an interesting tangential point. I wanted this field so that tools can use it, which implies some engineering upon those tools. That's really the reason why I asked here first - I didn't want myself or anybody else to have to go and rewrite some code they've just written if we change our minds here about where the location should be - as it seems is happening. Hope that helps. -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#904608: Support specifying upstream VCS location in debian/control
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 [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#904608: Support specifying upstream VCS location in debian/control
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 (d...@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 d...@packages.debian.org" > 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 Description: PGP signature
Bug#904608: Support specifying upstream VCS location in debian/control
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 (d...@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 d...@packages.debian.org" or "ask ftp-master", say. Thanks, Jonathan > [1] https://wiki.debian.org/UpstreamMetadata
Bug#904608: Support specifying upstream VCS location in debian/control
control: tag -1 +moreinfo Hello Iain, 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. In fact, there is: the Repository field in debian/upstream/metadata.[1] > 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. > > 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. [1] https://wiki.debian.org/UpstreamMetadata -- Sean Whitton signature.asc Description: PGP signature
Bug#904608: Support specifying upstream VCS location in debian/control
Package: debian-policy Version: 4.1.5.0 Severity: normal Hi, 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. 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. 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. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
