Re: BinNMU changelog handling for Multi-Arch: same packages
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
Reply to: