[Pkg-zsh-devel] Bug#770226: Bug#770226: zsh-common: installation fails for amd arch

[Scott Walsh]

Hi Axel,

I'll reply inline where necessary.

On 11/19/14, 7:33 PM, Axel Beckert wrote:
> Hi Scott,
> 
> thanks for the bug report.
> 
> Scott Walsh wrote:
>> aptitude install zsh, which lead to packages being in the 'half'
>> installed state. Attempting to purge was unsucessful. Had to resort to
>> dpkg --remove --force-remove-reinstreq zsh zsh-common to resolve the
>> issue.
> 
> That's strange, because I would expect that piuparts would find such
> issues, but definitely didn't, neither at
> https://piuparts.debian.org/sid/source/z/zsh.html nor at
> http://jenkins.grml.org/view/Debian/job/zsh-piuparts/
> 
>>   Preparing to unpack .../zsh-common_5.0.7-4_all.deb ...
>>   dpkg-maintscript-helper: error: original symlink target is not an
>>   absolute path
>>   dpkg: error processing archive
>>   /var/cache/apt/archives/zsh-common_5.0.7-4_all.deb (--unpack):
> 
> This is clearly something which was introduced by one of the fixes in
> 5.0.7-4 as we didn't use dpkg-maintscript-helper before.
> 
> I tried to reproduce this issue in a freshly bootstrapped jessie
> chroot, but couldn't (which doesn't surprise me much as piuparts
> couldn't either).
> 
> So we need to see what so special in your setup.

Nothing too special here. First system is month old netinstall that was
upgraded to testing. Nothing exotic too, other than adding 'contrib' and
'non-free' to the sources. The second system was installed at Lenny, and
dist-upgraded to new stables until Squeeze, at which point I converted
it to 'testing'. Both exhibit the same issue when installing zsh.
> 
> One thing which is a good candidate for such a failure is a too old
> dpkg version. Both, zsh and zsh-common have a "Pre-Depends: dpkg (>=
> 1.17.5)" because of this, but maybe that Pre-Depends is not strict
> enough (despite it has been set by debhelper for using
> dpkg-maintscript-helper with symlink_to_dir. But reading dpkg's
> changelog.Debian.gz, I find the following entry for 1.17.14:
> 
>   * Add support for relative symlinks to dpkg-maintscript-helper
>     symlink_to_dir command. [...]
> 
> So I suspect this happened with a dpkg version < 1.17.14 and we likely
> need to bump that Pre-Depends to >= 1.17.14.
> 
> Cc'ing debhelper-devel to make them aware of this potential issue.
> 
> debhelper maintainers: Shall I clone or reassign this bug report to
> debhelper for bumping ${misc:Pre-Depends} in such cases?
> 
> To be sure that my assumption is correct: Scott, can you tell me the
> dpkg version which was running at that time. If the dpkg has changed
> since then or was upgraded in the same run, please look in
> /var/log/aptitude or /var/log/dpkg.log which was installed when that
> error happened. (Verifying that dpkg was either uptodate in Jessie or
> below version 1.17.14 at the time when this happened should suffice.)

This was indeed the issue:

dpkg --version
Debian `dpkg' package management program version 1.17.13 (amd64).
This is free software; see the GNU General Public License version 2 or
later for copying conditions. There is NO warranty.

Upgrading to > 1.17.13 allowed zsh to install cleanly:

# dpkg --version
Debian `dpkg' package management program version 1.17.21 (amd64).
This is free software; see the GNU General Public License version 2 or
later for copying conditions. There is NO warranty.

# aptitude install zsh
The following NEW packages will be installed:
  zsh zsh-common{a}
0 packages upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/3,822 kB of archives. After unpacking 13.2 MB will be used.
Do you want to continue? [Y/n/?] y
Selecting previously unselected package zsh-common.
(Reading database ... 55941 files and directories currently installed.)
Preparing to unpack .../zsh-common_5.0.7-4_all.deb ...
Unpacking zsh-common (5.0.7-4) ...
Selecting previously unselected package zsh.
Preparing to unpack .../archives/zsh_5.0.7-4_amd64.deb ...
Unpacking zsh (5.0.7-4) ...
Processing triggers for man-db (2.7.0.2-3) ...

# which zsh
/usr/bin/zsh


Looks like a Pre-depends >= 1.17.14 will solve this issue in short order :)

Thanks for the quick replies and technical expertise! Also, thanks to
the anyone else involved as a packager/maintainer for taking the time to
do this, usually, thankless work!

Regards, Scott
> 
> 		Regards, Axel
>