Re: Handling of changelogs and bin-nmus

[Guillem Jover <guillem@debian.org>]

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 as long as it's in
> > machine parseable format) as dpkg metadata (something dpkg misses
> > compared to rpm or other package managers for example) and as such they
> > should go into the .deb control member, which would end up in the dpkg
> > database w/o any kind of file conflict, and very minor packaging effort
> > as for most that would be handled by helpers.
> 
> I agree that we should move into this direction. Still I believe it's
> important to distinguish "source changelog" and "binary changelog".
> And while we might not want to keep this distinction in the generated
> package, we should have it at the source package level.

> 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 do a bin-nmu
>   => it defines the ${binary:Version} and it's not included in
>   the generated source package

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
mentioned reasons against this in the ref-counting thread, and now
again in reply to Ian's mail.

> 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 might be
> interesting to share the same source package.

If the main purpose of this is to generalize the binNMU versioning
syntax then instead of entangling these different issues I think it's
way better to mark the changelog entry as such, so that there's actual
generic metadata that can be used by the tools, that does not need to
change the debian/changelog interface, neither modify other possible
parsers to look into different files, etc.

I've just cooked code to support this in dpkg, an example entry could
look like this (the binary-only key could be named something else):

,---
pkg (1.0-1+b1) unstable; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Reason.

 -- Guillem Jover <guillem@debian.org>  Tue, 12 Jun 2012 12:30:41 +0200

pkg (1.0-1) unstable; urgency=low

  * Some change.

 -- Guillem Jover <guillem@debian.org>  Sat, 09 Jun 2012 16:16:17 +0200
`---

Then dpkg-gencontrol and dpkg-genchanges check if the parser returns
a Binary-Only field, and if it does it parses the previous entry, and
passes the source and binary versions explicitly to the substvar module.

In addition dpkg-source refuses to proceed if Binary-Only is set.

> This is something that is on my relatively short-term TODO list for dpkg.
> Guillem, do you agree with this change?

No, I do not agree.

guillem