[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Handling of changelogs and bin-nmus



[ Dropping the bug report, moving the discussion to debian-dpkg too ]

Hi,

On Sun, 10 Jun 2012, Guillem Jover wrote:
> On Sat, 2012-06-09 at 15:26:06 +0200, Andreas Barth wrote:
> > However, we discussed that during the multi-arch bof last Debconf, and
> > came to the conclusion that it would be better to not modify the
> > changelog as we do now, but instead create a new file
> > changelog.$arch.$version with the binNMU. This is a bit more
> > complicated because it can't be done as of now just within the source
> > package.
> 
> 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

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.

With this change, current packages would always install the unmodified
changelog and the short term problem would be gone. And obviously it
doesn't preclude moving to the long term solution that you presented.
Instead of just copying debian/changelog to pkg/DEBIAN/ it would copy both
files (or the result of their concatenation).


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

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


Reply to: