Sigh, again... On Wed, 2012-07-11 at 09:23:05 +0200, Raphael Hertzog wrote: > On Wed, 20 Jun 2012, Guillem Jover wrote: > > I'll be doing a first push today. The remaning things I'll be finishing > > up next are at least the strings cleanup left out from the 1.16.4 > > release, the cross-multiarch patches, part of the changelog binNMU > > solution, and some other multiarch related improvements. > > So it looks like that the "part of the changelog binNMU solution" > was just the possibility to tag a changelog entry "binary-only" > with a keyword.
> But that doesn't solve the release team's problem of having to schedule > bin-nmus for all arches for Multi-Arch: same. No, the part of the solution was to create the needed user and program infrastructure interfaces to retrieve the metadata files from the db in a future-proof way. That's the new commands «dpkg-query --control-list pkg» and «dpkg-query --control-show pkg file», which should eventually replace the previous semi-private «dpkg-query --control-path pkg [file]». There's no other changes required from the dpkg side. To get changelog (and possibly copyright files) as package metadata, I think the only remaining things that would need to happen if the project agreed that's the right path would be: * Change apt-listchanges to use «dpkg-deb -I pkg changelog» to try to get the package changelog. * Change the “website” to use «dpkg-deb -I pkg changelog» to try to get the package changelog (and possibly copyright). * Change policy to allow packages to ship changelogs (and possibly copyright) as package metadata instead of «/use/share/doc/<pkg>/». * Change lintian per the above. * Change dh_installchangelogs to install the changelog in the DEBIAN/ dir instaed of «/use/share/doc/<pkg>/». * Progressively change any remaning package not using debhelper to store these under DEBIAN/. ? If there's any program showing changelog files from installed paths switch them to use «dpkg-query --control-show pkg changelog». > I know that in the long term you're in favor of moving the changelog in > the package metadata and I agree with this plan. But IMO we must find > an interim solution in the mean time. First, I don't see why we _must_, it's been a known limitation of the spec for a long time and as Julien said now it's probably too late anyway, there's always the possibility for a last sourceful upload before the release, and I've said before I think a solution to this should really not be rushed... *But* if something needed to be done, I keep failing to see the point in temporary hacks which imply, as much if not more work (as it needs to be reverted back and switched to the new scheme) or wrongness, instead of just going for the metadata solution... > Here's a suggestion. Please share your thoughts: > > 1/ we modify dh_installchangelog to strip the binary-only changelog entry > for Multi-Arch: same packages > > Some rough shell code to show the logic: > > if dpkg-parsechangelog | grep -q "^Binary-Only: yes"; then > perl -i -ne '$found++ if /^\S/; print if $found >= 2;' $changelog > fi For packages not using debhelper this would need to be duplicated all over the place, to later on having to be reverted. > 2/ we modify dpkg to allow co-installation of M-A: same packages which share > the > same source version regardless of the binary version As I've said before, this right here seems unacceptable. This implies at least: * loosing the binNMU changelog entry, with a version in the changelog not matching the one on the dpkg db (in possibly both directions). * making installed file contents flip-flop depending on what package got installed last. * making dpkg unable to detect different generated file contents on different binary rebuilds. > 3/ we modify sbuild to add the required "binary-only=yes" in the binNMU > changelog entries. Here's a sample header line: > > ftplib (3.1-1-9+b1) unstable; urgency=low, binary-only=yes This could be done regardless if the buildd people agree to it, and that was the idea when I added this. guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
