Re: Handling of changelogs and bin-nmus
Guillem Jover <guillem@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 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.
But if a binNMU changes debian/changelog then that change ends up in the
binary package. And that means you get a file collision for multiarch
where 2 packages contain the same file name but different contents.
So what is your solution there?
And no, moving the changelog to a -common deb does not solve the problem
since the binNMU would require a new -common deb while the original
wants the old one.
MfG
Goswin
Reply to: