[Pkg-zsh-devel] Bug#890711: Bug#890711: zsh-common: Missing Depends on zsh

[Dima Kogan]

Axel Beckert <abe at debian.org> writes:

> Hi Dima,

Hi! Thanks for replying


>> During an upgrade I ended up in this situation:
>>
>>  $ dpkg -l | grep zsh
>>  ii  zsh                             4.3.17-1                         amd64        shell with lots of features
>>  ii  zsh-common                      5.4.2-3                          all          architecture independent files for Zsh
>
> Wait. That would have been a dist-upgrade from Wheezy (old-old-stable)
> to Testing in one run? Skipping two releases is surely not supported.

Honestly, I don't remember. This is an old web server that I THINK was
mostly jessie, but had sid enabled in its sources.list (I only realized
this after I did the upgrade). And I did a plain "aptitude update",
"aptitude upgrade".


> Additionally, what did pull in zsh-common? zsh 4.3.17-1 is not yet
> split up and has no dependency on zsh-common, not even an unversioned
> one. (Which probably means that zsh-common rather would need a
> "Conflicts: zsh (<< 5)", but fixing this three releases later seems
> ridiculous.)

Just looked at the logs. aptitude tried to upgrade zsh to 5.4.2-3, which
pulled in zsh-common. During the upgrade something didn't go right, and
I guess zsh ended up at the old version, but zsh-common did get
installed.

I just looked at the logs, and the failure was surely due to this being
a large-step upgrade (I didn't realize I was doing anything interesting
when I was doing it). Still have the log, and can tell you exactly what
went wrong if you want, but it probably doesn't matter for THIS issue. I
ran "aptitude install -f", and as far as apt was concerned there were no
issues after this.


> Besides, zsh 5.4.2-3 has a hard, versioned dependency on zsh-common:
>
> Package: zsh
> Version: 5.4.2-3
> Depends: zsh-common (= 5.4.2-3), [ ]
>
>> And together I get weird errors any time I press TAB to invoke
>> completion:
>>
>>  $ ls [pressed TAB]
>>  (eval):setopt:3: no such option: localpatterns
>>  (eval):setopt:3: no such option: NO_warnnestedvar
>
> Such errors are IIRC normal during dist-upgrades, even if you have
> both, zsh and zsh-common updated, but still old zsh processes running.
> As soon as both, zsh and zsh-common are uptodate again, calling "exec
> zsh" fixes it.

Right. Until I manually re-upgraded zsh, this was a persistent problem.


>> This is because here zsh-common was massively newer than zsh. We can add
>>
>>  Depends: zsh (= ${binary:Version})
>>
>> to the zsh-common definition. Is this too strong?
>
> I really would like to avoid circular dependencies and I also see no
> reason for such a dependency. (See above for the reasoning.)

OK. Before you mentioned it I didn't realize that this install was as
old as it apparently is, so maybe leaving it is ok. Upgrades such as
this maybe aren't common, but people do do them, and this harder
dependency would save them time. I filed this bug in case this missing
dep was an oversight, but you clearly thought about it, and if you think
the downsides of adding such a dependency outweigh the benefits, feel
free to close this bug.

Thanks!