Re: More Vcs-Fields in debian/control?
On Tue, Apr 19, 2011 at 09:43:45PM -0400, Yaroslav Halchenko wrote: On Thu, 07 Apr 2011, Jan Hauke Rahm wrote: No. Simply answer the question: Is this VCS used by derived distros, too? If not, it's Debian only. Two examples: The git repository for apt-mirror is used only for Debian (there's only the master branch). The git repository for vlc is used for Debian and Ubuntu (master branch for Debian sid, squeeze branch for Debian squeeze, ubuntu branch for Ubuntu natty, maverick branch for Ubuntu maverick, and so on). And why would we care? We keep track of what we do. Anyone else may use it or leave it. In an ideal world of mine, for any package I maintain I would have all interesting repositories linked to: upstream, Debian packaging, popular distribution X, Y, Z packaging etc. This way I could easily track the software life outside of upstream-Debian pipe so I could improve Debian side by possibly rapidly reacting to bugs/fixes introduced elsewhere and haven't reached upstream yet, but already included in X, Y, Z. I can only encourage you to do so. Everything (almost :)) that makes your packages, and thus Debian, better is a good thing. So, altogether, the idea of having more than Debian + upstream VCS fields is sound to me. Approach/Implementation is being discussed elsewhere in this thread. The problem now is imo that if we (as in Debian) were to put whatever kind of tracking fields in our packages that relate to popular distributions, we are making a statement. You, as a maintainer, can of course collect as much information from anywhere, and you have the right to only collect such from popular distributions. I don't think Debian should do that, though, since Debian would then single out projects as more worth looking at than others. In our qa infrastructure, we already acknowledge that Ubuntu has become sort of the biggest derivative of Debian. That's enough. There are projects (such as vcs-pkg) that try to make collaboration between distributions easier and I think that's where we can collect information that can help maintainers. I'd appreciate action on that part but not in debian/control. (And if any such project would implement some $clever technique that would allow easy tracking of what others do, we might consider making use of that in Debian, instead of changing each and every package once a derivative becomes popular.) Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: More Vcs-Fields in debian/control?
On Thu, 07 Apr 2011, Jan Hauke Rahm wrote: No. Simply answer the question: Is this VCS used by derived distros, too? If not, it's Debian only. Two examples: The git repository for apt-mirror is used only for Debian (there's only the master branch). The git repository for vlc is used for Debian and Ubuntu (master branch for Debian sid, squeeze branch for Debian squeeze, ubuntu branch for Ubuntu natty, maverick branch for Ubuntu maverick, and so on). And why would we care? We keep track of what we do. Anyone else may use it or leave it. In an ideal world of mine, for any package I maintain I would have all interesting repositories linked to: upstream, Debian packaging, popular distribution X, Y, Z packaging etc. This way I could easily track the software life outside of upstream-Debian pipe so I could improve Debian side by possibly rapidly reacting to bugs/fixes introduced elsewhere and haven't reached upstream yet, but already included in X, Y, Z. So, altogether, the idea of having more than Debian + upstream VCS fields is sound to me. Approach/Implementation is being discussed elsewhere in this thread. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420014345.gj7...@onerussian.com
Re: More Vcs-Fields in debian/control?
On Sat, Apr 09, 2011 at 11:57:58AM +0900, Charles Plessy wrote: YAML is also used in other Debian processes, like for instance some reports generated by the FTP team. All in all, I do not have the impression that the use of YAML would cause difficulties to Debian packages maintainers. The fact that people are rising concerns about the format *now* (after it is used (and announced) over a year is for me a proof that the pure existence of this file is widely unknown. If the *format* would be *really* the only issue why it is that seldomly used we should simply discuss the format and agree to something which is really used afterwards. If you just enjoy format discussion and do not intend to use the file there are better ways to spend someones time. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409190654.ga15...@an3as.eu
Re: More Vcs-Fields in debian/control?
Le Thu, Apr 07, 2011 at 03:08:33PM +0200, Bernd Zeimetz a écrit : On 04/07/2011 10:11 AM, Charles Plessy wrote: http://wiki.debian.org/UpstreamMetadata The key concept is to store ‘Field: value’ data in a file called debian/upstream-metadata.yaml, and to access it from the VCS where the package is stored (that is, not from the source package itself). Uh please not yet another file in yet another format. If you really need yet another file, please don't use yet another markup language, use something RFC822ish. Hi Bernd, I think that the format used in Debian control data files only shows superiority when they consist of multiple paragraphs, in particular when these are ordered. For single paragraphs, YAML is actually very similar to Debian's control data files. The advantage of YAML is the availability of many facilities like parsers, command-line and on-line validators, and documentation. YAML is also used in other Debian processes, like for instance some reports generated by the FTP team. All in all, I do not have the impression that the use of YAML would cause difficulties to Debian packages maintainers. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409025758.gb13...@merveille.plessy.net
Re: More Vcs-Fields in debian/control?
On Wed, 06 Apr 2011, Russ Allbery wrote: So I can still see the point of somewhere adding a pointer to the upstream VCS repository. However, is the control file really the right place for that? I guess we don't have a better place right now, but this doesn't feel like package metadata that needs to be put into the Sources file. +1 And I'm not really keen on recognizing more Vcs-* fields in debian/control as far as dpkg-dev is concerned. There are lots of upstream-metadata that we might want to have available and we need to find a proper solution that doesn't involve debian/control. It should be outside of the package and probably shared accross all Linux distributions. It seems to me to be a good extension of the work done/planned on the cross-distribution app-store. http://distributions.freedesktop.org/wiki/AppStream/Implementation Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407062206.gc29...@rivendell.home.ouaza.com
Re: More Vcs-Fields in debian/control?
Joey Hess jo...@debian.org writes: I would instead suggest we deprecate packages not including upstream source in their VCS. The weight of progress is against that practice; It is? Where can I read about this supposed weight of progress? Keeping the debian packaging files in a separate repository suits me just fine. tools have improved so there is little excuse to do it Which tools in particular? Are you accounting for the full suite of VCSen that Debian's ‘VCS-*’ fields allow for? it increasingly violates expections and makes things harder. Some examples: * git cherry-pick cannot be used I can't speak to that one as I don't know what the problems are. * pristine-tar cannot be used The assumptions of ‘pristine-tar’ seem very Git-centric and are quite at odds with my chosen VCS (Bazaar). It demands a “treeish object”, I have no idea what that relates to in Bazaar. * apt-get source now suggests running debcheckout when VCS fields are present. But for such a package, debcheckout won't result in the same source tree as does apt-get source. That sounds like a poor recommendation, then :-) Adding baroque complications to the VCS fields doesn't deal with these problems consistently I agree that it's undesirable to add baroque complications to the ‘VCS-*’ fields. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but if the plural of mouse is mice, wouldn't the plural | _o__) of spouse be spice?” —_Pinky and The Brain_ | Ben Finney pgpPDlg8YYQXQ.pgp Description: PGP signature
Re: More Vcs-Fields in debian/control?
Russ Allbery r...@debian.org writes: If upstream is using some other weird thing like bzr or Mercurial or whatnot, we're now getting into rather more effort than I'd personally want to bother with. If Bazaar and Mercurial are “some other weird thing”, that doesn't bode well for the future of the Debian tools interacting with VCSen. Is any VCS other than Git to be deprecated? -- \ “Unix is an operating system, OS/2 is half an operating system, | `\Windows is a shell, and DOS is a boot partition virus.” —Peter | _o__)H. Coffin | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3kyftzo@benfinney.id.au
Re: More Vcs-Fields in debian/control?
Ben Finney ben+deb...@benfinney.id.au writes: Russ Allbery r...@debian.org writes: If upstream is using some other weird thing like bzr or Mercurial or whatnot, we're now getting into rather more effort than I'd personally want to bother with. If Bazaar and Mercurial are “some other weird thing”, that doesn't bode well for the future of the Debian tools interacting with VCSen. Is any VCS other than Git to be deprecated? You are both taking out of context a specific example within a larger discussion that had nothing to do with your reply, and attributing to me rather impressive and stunning power over Debian as a whole. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762qqd0hb@windlord.stanford.edu
Re: More Vcs-Fields in debian/control?
Russ Allbery r...@debian.org writes: You are both taking out of context a specific example within a larger discussion that had nothing to do with your reply, and attributing to me rather impressive and stunning power over Debian as a whole. :) I object! How dare you call me short! :-) -- \ “What we usually pray to God is not that His will be done, but | `\ that He approve ours.” —Helga Bergold Gross | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hb6ftaa@benfinney.id.au
Re: More Vcs-Fields in debian/control?
OoO En cette aube naissante du jeudi 07 avril 2011, vers 07:46, Joey Hess jo...@debian.org disait : We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] I would instead suggest we deprecate packages not including upstream source in their VCS. The weight of progress is against that practice; tools have improved so there is little excuse to do it, it increasingly violates expections and makes things harder. Some examples: * git cherry-pick cannot be used * pristine-tar cannot be used * apt-get source now suggests running debcheckout when VCS fields are present. But for such a package, debcheckout won't result in the same source tree as does apt-get source. Adding baroque complications to the VCS fields doesn't deal with these problems consistently, and while it might help this style of VCS use linger a while longer, it will be an unnecessary complication going forward. Large SVN repositories containing only debian/ directories are already quite slow (at least on alioth). Adding upstream sources (and history) would not improve this part. Moreover, do we have space to cope with this? -- I AM NOT MY LONG-LOST TWIN I AM NOT MY LONG-LOST TWIN I AM NOT MY LONG-LOST TWIN -+- Bart Simpson on chalkboard in episode 4F03 pgp3JGLhwZXHe.pgp Description: PGP signature
Re: More Vcs-Fields in debian/control?
Le Wed, Apr 06, 2011 at 10:53:55PM -0700, Russ Allbery a écrit : However, is the control file really the right place for that? I guess we don't have a better place right now, but this doesn't feel like package metadata that needs to be put into the Sources file. Hi, there is my pet project about upstream metadata: http://wiki.debian.org/UpstreamMetadata The key concept is to store ‘Field: value’ data in a file called debian/upstream-metadata.yaml, and to access it from the VCS where the package is stored (that is, not from the source package itself). This allows: - To update the data without uploading the package; - to distribute a reasonnably up-to-date copy with our source packages. I have not yet found time to push for finishing the proof of principle, which is to collect bibliographic information for the Blends websites through that system via the UDD, but it would be straightforward to use it right now for packages managed in Git and Subversion. Adding support for other VCSes should be trivial. For packages that are not managed in a VCS, I think that the most realistic solution would be to maintain the metadata in a special flat file on collab-maint. (And I also support deprecating the non-use of VCS for managing source packages). The biggest difficulty would be to agree on field names. The best would be to be compatible with some pre-existing RDF ontologies, like DOAP. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407081113.gd9...@merveille.plessy.net
Re: More Vcs-Fields in debian/control?
On Thu, Apr 7, 2011 at 1:46 PM, Joey Hess jo...@debian.org wrote: I would instead suggest we deprecate packages not including upstream source in their VCS. The weight of progress is against that practice; tools have improved so there is little excuse to do it, it increasingly violates expections and makes things harder. As someone who works in pkg-games where upstreams commonly include non-free material, many embedded code copies and hundreds of megabytes of data, I don't agree with this. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinm=81avi6qtfwyjjvp_ybgw+k...@mail.gmail.com
Re: More Vcs-Fields in debian/control?
On Thu, Apr 07, 2011 at 08:22:06AM +0200, Raphael Hertzog wrote: There are lots of upstream-metadata that we might want to have available and we need to find a proper solution that doesn't involve debian/control. In Debian Med and Debian Science we are just using http://wiki.debian.org/UpstreamMetadata for keeping scientific references. Bu tthe idea is not restricted to this. There exists an UDD importer for these data. It should be outside of the package and probably shared accross all Linux distributions. It seems to me to be a good extension of the work done/planned on the cross-distribution app-store. I do not see a reason why this should not be possible with the proposed solution. It's just not (yet) widely adopted in Debian. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407122039.gf15...@an3as.eu
Re: More Vcs-Fields in debian/control?
On 04/07/2011 10:11 AM, Charles Plessy wrote: http://wiki.debian.org/UpstreamMetadata The key concept is to store ‘Field: value’ data in a file called debian/upstream-metadata.yaml, and to access it from the VCS where the package is stored (that is, not from the source package itself). Uh please not yet another file in yet another format. If you really need yet another file, please don't use yet another markup language, use something RFC822ish. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9db751.1060...@bzed.de
Re: More Vcs-Fields in debian/control?
On Thu, 2011-04-07 at 16:33 +1000, Ben Finney wrote: Joey Hess jo...@debian.org writes: * pristine-tar cannot be used The assumptions of ‘pristine-tar’ seem very Git-centric and are quite at odds with my chosen VCS (Bazaar). It demands a “treeish object”, I have no idea what that relates to in Bazaar. pristine-tar checkout is git specific as far as I can tell, but the other commands are very well usable without git. bzr-builddeb supports pristine tar and uses it to import and export upstream tarballs if you have a packaging branch that includes the upstream source. Cheers, Jelmer signature.asc Description: This is a digitally signed message part
More Vcs-Fields in debian/control?
Hi -devel! We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] My suggestion would even go further (attention, I have NO idea how debian/control is parsed and how much work the following would be): Let's make that Vcs-Vendor with Vendor (like in DEP3) Debian, Upstream, Ubuntu, Whoever-else-uses-the-packaging. Opinions? Regards Evgeni -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9c3b1f.4060...@debian.org
Re: More Vcs-Fields in debian/control?
Am Mittwoch, den 06.04.2011, 12:06 +0200 schrieb Evgeni Golov: Hi -devel! We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] My suggestion would even go further (attention, I have NO idea how debian/control is parsed and how much work the following would be): Let's make that Vcs-Vendor with Vendor (like in DEP3) Debian, Upstream, Ubuntu, Whoever-else-uses-the-packaging. Opinions? I like this idea. There should be a Vcs-Debian-* too and used in most cases. A package should use Vcs-Debian-* if the vcs is only used in Debian. A package could use Vcs-* if the vcs is used in derived distros too. What should we do if we have multiple upstream VCSes? For exapmle, Eclipse has Eclipse and eclipse-build as upstream. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: More Vcs-Fields in debian/control?
On Wed, Apr 06, 2011 at 12:28:39PM +0200, Benjamin Drung wrote: We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] My suggestion would even go further (attention, I have NO idea how debian/control is parsed and how much work the following would be): Let's make that Vcs-Vendor with Vendor (like in DEP3) Debian, Upstream, Ubuntu, Whoever-else-uses-the-packaging. I like this idea. There should be a Vcs-Debian-* too and used in most cases. A package should use Vcs-Debian-* if the vcs is only used in Debian. A package could use Vcs-* if the vcs is used in derived distros too. What do you mean, only used in Debian? Do you expect Debian maintainers to track whether or not downstreams have a separate VCS? I don't think this is the right way to do it any more than we should rename 'Maintainer' to 'Maintainer-Debian'. If downstreams diverge, it should be up to them to kee the information in debian/control current. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: More Vcs-Fields in debian/control?
Am Mittwoch, den 06.04.2011, 11:39 -0700 schrieb Steve Langasek: On Wed, Apr 06, 2011 at 12:28:39PM +0200, Benjamin Drung wrote: We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] My suggestion would even go further (attention, I have NO idea how debian/control is parsed and how much work the following would be): Let's make that Vcs-Vendor with Vendor (like in DEP3) Debian, Upstream, Ubuntu, Whoever-else-uses-the-packaging. I like this idea. There should be a Vcs-Debian-* too and used in most cases. A package should use Vcs-Debian-* if the vcs is only used in Debian. A package could use Vcs-* if the vcs is used in derived distros too. What do you mean, only used in Debian? Do you expect Debian maintainers to track whether or not downstreams have a separate VCS? No. Simply answer the question: Is this VCS used by derived distros, too? If not, it's Debian only. Two examples: The git repository for apt-mirror is used only for Debian (there's only the master branch). The git repository for vlc is used for Debian and Ubuntu (master branch for Debian sid, squeeze branch for Debian squeeze, ubuntu branch for Ubuntu natty, maverick branch for Ubuntu maverick, and so on). I don't think this is the right way to do it any more than we should rename 'Maintainer' to 'Maintainer-Debian'. If downstreams diverge, it should be up to them to kee the information in debian/control current. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: More Vcs-Fields in debian/control?
On Wed, Apr 06, 2011 at 08:55:05PM +0200, Benjamin Drung wrote: Am Mittwoch, den 06.04.2011, 11:39 -0700 schrieb Steve Langasek: On Wed, Apr 06, 2011 at 12:28:39PM +0200, Benjamin Drung wrote: There should be a Vcs-Debian-* too and used in most cases. A package should use Vcs-Debian-* if the vcs is only used in Debian. A package could use Vcs-* if the vcs is used in derived distros too. What do you mean, only used in Debian? Do you expect Debian maintainers to track whether or not downstreams have a separate VCS? No. Simply answer the question: Is this VCS used by derived distros, too? If not, it's Debian only. Two examples: The git repository for apt-mirror is used only for Debian (there's only the master branch). The git repository for vlc is used for Debian and Ubuntu (master branch for Debian sid, squeeze branch for Debian squeeze, ubuntu branch for Ubuntu natty, maverick branch for Ubuntu maverick, and so on). And why would we care? We keep track of what we do. Anyone else may use it or leave it. Let's please not invent another special case for Ubuntu just because they're big or fancy[TM] at the moment. And no, I definitely don't want VCS-derived-by-* for each and every derived distro to make Ubuntu not so special-cased... Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: More Vcs-Fields in debian/control?
Evgeni Golov wrote: We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] I would instead suggest we deprecate packages not including upstream source in their VCS. The weight of progress is against that practice; tools have improved so there is little excuse to do it, it increasingly violates expections and makes things harder. Some examples: * git cherry-pick cannot be used * pristine-tar cannot be used * apt-get source now suggests running debcheckout when VCS fields are present. But for such a package, debcheckout won't result in the same source tree as does apt-get source. Adding baroque complications to the VCS fields doesn't deal with these problems consistently, and while it might help this style of VCS use linger a while longer, it will be an unnecessary complication going forward. -- see shy jo signature.asc Description: Digital signature
Re: More Vcs-Fields in debian/control?
Joey Hess jo...@debian.org writes: Evgeni Golov wrote: We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] I would instead suggest we deprecate packages not including upstream source in their VCS. The weight of progress is against that practice; tools have improved so there is little excuse to do it, it increasingly violates expections and makes things harder. While I agree with this, I think the problem that they're trying to solve is getting the upstream revision history, not just a copy of the source. The Debian repository may contain only snapshots of releases imported via git-import-orig or the like, rather than the complete revision history. Having the complete revision history is definitely nice, and I've started doing that with a few upstreams that use Git, but it's a bit more complicated to get the details sorted out. If upstream is using something like Subversion or CVS, it's even more complicated, although there are some Git tools that mostly work (at least for Subversion; CVS is another matter). If upstream is using some other weird thing like bzr or Mercurial or whatnot, we're now getting into rather more effort than I'd personally want to bother with. So I can still see the point of somewhere adding a pointer to the upstream VCS repository. However, is the control file really the right place for that? I guess we don't have a better place right now, but this doesn't feel like package metadata that needs to be put into the Sources file. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipuqd2to@windlord.stanford.edu
