Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
On Tue, 14 Feb 2012, Philipp Kern wrote:
> On 2012-02-14, Raphael Hertzog <email@example.com> wrote:
> > Somehow my suggestion is then to extend dpkg-parsechangelog to provide
> > the required logic to split the changelog in its bin-nmu part and its
> > usual content.
> > dpkg-parsechangelog --split-binnmu <binnmu-part-file> <remaining-part-file>
> > Then dh_installchangelogs could try to use this (and if it fails, fallback
> > to the standard changelog installation).
> > Does that sound sane? If yes, I can have a look at implementing this.
> In theory sbuild could also offload this to dpkg-buildpackage by passing
> something like "--binnmu-version 2 --binnmu-changelog 'Rebuild for libfoo
> transition'". The only thing that would be annoying is checking if the old
> style or the new style must be used. (I.e. there must be some sort of feature
> query first.)
Yes but that doesn't change anything to the fact that dpkg-dev should not
install files in the generated .deb. So we still need some interaction
with dh_installchangelogs... but your suggestion lead me to another
dpkg-buildpackage --binary-version <ver> --binary-changelog 'foo'
could create debian/changelog.build with the given changelog version and
dpkg-parsechangelog could be taught to read debian/changelog.build
before debian/changelog so that dpkg-parsechangelog continues to do the
right thing (when called from debian/rules).
And dh_installchangelogs can be taught to install debian/changelog.build
dpkg-buildpackage would clean up debian/changelog.build if it wasn't
passed the proper option. dpkg-source would learn to not include it in
generated source packages, too.
This looks like rather appealing to me. What do you think?
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/