[Pkg-zsh-devel] Bug#768937: Bug#768937: zsh: [patch] not binNMU-safe due to --link-doc between arch-dep and arch-indep

[Axel Beckert]

Hi Simon,

Simon McVittie wrote:
> On 11/11/14 02:10, Axel Beckert wrote:
> > I'm not yet sure what's the culprit, but after applying your patch
> > (without the changelog) to the current HEAD of our packging git repo,
> > the installation of zsh-common always aborts as follows:
> > 
> > Preparing to unpack zsh-common_5.0.7-4_all.deb ...
> > Unpacking zsh-common (5.0.7-4) over (5.0.7-3+0~20141111001757.238~1.gbp353e05) ...
> > dpkg: error processing archive zsh-common_5.0.7-4_all.deb (--install):
> >  unable to open '/usr/share/doc/zsh-common/ChangeLog-3.0.gz.dpkg-new': No such file or directory
> 
> Huh. Sorry, it worked for me...

Yeah, I was also surprised. I've built it at least two or three times
and it was happening reproducibly.

Compared to 5.0.7-3, git HEAD[1] so far only sports a one-line fix for
#768241 (zsh: leaves alternatives after purge: /bin/rzsh = /bin/zsh4)
in zsh.postinst plus some documentation changes, so that shouldn't
cause such issues.

Additionally with the packages built by Jenkins from git HEAD[1], i.e.
including the #768241 fix, this issue does not appear.

[1] https://anonscm.debian.org/cgit/collab-maint/zsh.git/log/

> > I currently suspect that dpkg-maintscript-helper may be confused
> > because because /usr/share/doc/zsh is now a directory inside zsh _and_
> > zsh-common.
> 
> Perhaps. If that's the case, one way to solve it would be to move the
> symlinks from zsh-common into zsh;

Yeah, I was also thinking about that because I initially disliked the
fact that /usr/share/doc/zsh was also part of zsh-common ...

> but because they're built in separate Makefile targets,

... but I then noticed this, too. and then thought that your solution
is better than I initially expected. :-)

> and some of the target files are compressed whereas others aren't,

IIRC dh_compress handles at least some of these cases, but I'm not
sure which and which not.

> that would involve either some awkward hard-coding,

I don't think it's that awkward. Actually I'm considering this being a
not so inconvenient solution.

> or doing zsh-common's dh_installdocs, dh_installchangelogs,
> dh_installexamples and dh_compress even though not actually building
> zsh-common.

That sounds more awkward to me.

> At this point I would be very tempted to duplicate NEWS.Debian and
> README.Debian in the zsh package, not bother with symlinks for the rest,
> and mention in README.Debian that various extra bits of documentation,
> including the upstream changelog, can now be found in
> /usr/share/doc/zsh-common.

That's an option, too, indeed. Not the nicest one, but one which
is likely to not cause any technical headaches.

Will think about these ideas and do some more testing. Thanks for your
comments and input!

I'll reply the remainder of your mail to bug #469521 as I think it's
more or less irrelevant for this RC bug.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5