Re: Handling of changelogs and bin-nmus

2012-06-13 Thread Goswin von Brederlow
Guillem Jover guil...@debian.org writes: On Sun, 2012-06-10 at 14:40:28 +0200, Raphael Hertzog wrote: On Sun, 10 Jun 2012, Guillem Jover wrote: As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think

Re: Handling of changelogs and bin-nmus

2012-06-12 Thread Raphael Hertzog
Hi, On Sun, 10 Jun 2012, Andreas Barth wrote: Asking to be sure: For sbuild, that means instead of changing the file debian/changelog before starting the build, a new file debian/changelog.binary-rebuild (or however it is named) is created and from there on all works by itself? That's the

Re: Handling of changelogs and bin-nmus

2012-06-12 Thread Guillem Jover
On Sun, 2012-06-10 at 14:40:28 +0200, Raphael Hertzog wrote: On Sun, 10 Jun 2012, Guillem Jover wrote: As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright

Re: Handling of changelogs and bin-nmus

2012-06-12 Thread Raphael Hertzog
Hi, On Tue, 12 Jun 2012, Guillem Jover wrote: This allows us to get rid of the special-casing of bin-nmu in dpkg where we only support one extension (+bX). We have many other cases where it would be helpful to be able to do such binary-only rebuild in different environments and where it

Re: Handling of changelogs and bin-nmus

2012-06-12 Thread Uoti Urpala
Guillem Jover wrote: By definition a binNMU cannot produce a source package anyway, so I fail to see the point in this artifical need to distinguish “source” and “binary” changelogs through different files, AFAIR I already Why artificial? Isn't it a completely natural and consistent view to

Re: Handling of changelogs and bin-nmus

2012-06-12 Thread Andreas Barth
* Raphael Hertzog (hert...@debian.org) [120612 13:10]: 1/ we modify dpkg to ignore differences on /usr/share/doc/*/changelog.*gz for multi-arch: same packages Doesn't sound too bad to me, at least for short-term (where I'd tend to take the changelog-version of the main architecture on

Re: Handling of changelogs and bin-nmus

2012-06-10 Thread Jonathan Nieder
Raphael Hertzog wrote: As such, I suggest that we handle binary rebuild differently: - debian/changelog is left unmodified since it's the source changelog = it defines the ${source:Version} substvar - debian/changelog.binary-rebuild (or any other better name) is created when we want to

Re: Handling of changelogs and bin-nmus

2012-06-10 Thread Raphael Hertzog
On Sun, 10 Jun 2012, Jonathan Nieder wrote: Raphael Hertzog wrote: As such, I suggest that we handle binary rebuild differently: - debian/changelog is left unmodified since it's the source changelog = it defines the ${source:Version} substvar - debian/changelog.binary-rebuild (or any

Re: Handling of changelogs and bin-nmus

2012-06-10 Thread Andreas Barth
* Raphael Hertzog (hert...@debian.org) [120610 20:44]: On Sun, 10 Jun 2012, Jonathan Nieder wrote: Raphael Hertzog wrote: As such, I suggest that we handle binary rebuild differently: - debian/changelog is left unmodified since it's the source changelog = it defines the

Re: Handling of changelogs and bin-nmus

2012-06-10 Thread Jonathan Nieder
Andreas Barth wrote: Do we have other tools than dpkg that parse the changelog to find out the package version? Yes, debian/rules parses the changelog in a low-tech way in some source packages. Someone with access to the lintian lab might be able to say how many packages would be hurt by not