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 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehpjo8u1.fsf@frosties.localnet