Re: BinNMU changelog handling for Multi-Arch: same packages
On Thu, 12 Jul 2012, Guillem Jover wrote:
> Sigh, again...
There's no need to "sigh" every time I try to discuss something with
you... I'm not trying to impose anything but just wanted to get a clearer
picture of the situation. And this imposes some communication between us.
Sorry for that.
> On Wed, 2012-07-11 at 09:23:05 +0200, Raphael Hertzog wrote:
> > 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.
>
> 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]».
Oh, ok. That makes sense. Now we have the correct interface in wheezy so
that other programs can start to rely on it in wheezy + 1.
> 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/.
We should then probably open a bug against debian-policy. I'm doing it
now. We can then discuss there whether we need to find a solution
so that we're never in situation where neither the direct access nor the
command can be trusted to work. For the /usr/doc transition we created
symlinks for this purpose but it has been a painful transition due to
this.
Discussion shall continue in #681289.
> > 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
Right, I should have said "IMO we should find".
> > 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.
There's a mis-understanding here. I was not telling to drop the check
that ensures that the files are identical between the various arches.
Instead I'm just saying that we must change the check that ensures that
all package are at the same version to use the source version and not the
binary version.
And this is required even if we move the changelog to control.tar.
Otherwise the release team will still have to bin-nmu all arches at the
same time, which is what they would like to avoid.
> > 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.
Filed a bug for this.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: