[Pkg-zsh-devel] Bug#808977: Bug#808977: zsh-common: Please add Multi-Arch: foreign

[Elrond]

Hi,

On Thu, Dec 31, 2015 at 01:37:24 +0100, Axel Beckert wrote:
> Hi,
> 
> Elrond wrote:
> > > > - The "Depends: zsh" probably should be "zsh:any"
> > > 
> > > Done, thanks.
> > 
> > ... because I think, that zsh:any requires zsh to have a
> > "Multi-Arch: allowed" tag. Otherwise you can't satisfy the
> > dependency.
> 
> Re-reading
> https://wiki.debian.org/Multiarch/CrossDependencies#When_shouldn.27t_I_add_M-A:_foreign.3F
> I'm reluctant to add "Multi-Arch: allowed" to the zsh package.
> 
> As far as I understand it this would mean that e.g. zsh:armhf would
> satisfy z-sy-h's zsh:any dependency on an amd64 system where armhf
> packages are installed for cross-compiling. That seems wrong.

Well, installing a non runnable binary package isn't useful
in most cases anyway.
As an extreme example: bash is "Multi-Arch: foreign".  So
any bash will satisfy any dependency.

Using qemu-something, I think you can run armhf even on
amd64 boxes. So yes, all of that might work.

In other words: If you "dpkg --add-architecture armhf"
(which is the first step to actually being able to install
zsh:armhf) on say an amd64 system, you're promissing, that
armhf either runs nicely on this system, or that you're
being careful.


> OTOH, this would also mean that zsh:i386 would satisfy that dependency
> on an amd64 system -- which would work, but IMHO is neither helpful
> nor a real use case.
[...]
> Or does anyone knows a real use case for zsh in a multiarchy
> environment where any of the multiarchy features is really required?

There are some cases here:

1. My personal one: I am trying to cross-grade some boxes
   from i386 to amd64.  There are multiple ways to do that,
   but it is much, much smoother with correct m-a-tagging,
   really.  zsh-common just was on my "It would be much
   easier, if that one is foreign" list.

A bit academic:

2. Maybe people want to cross-grade zsh to x32 in the
   future, if/when it becomes more wide spread. It seems a
   good candidate: It likely doesn't need more than 2 GB of
   RAM in 99.99% of the cases, but could benefit from 64
   bit registers. So making zsh m-a-ready now will make x32
   more usable in the future.

Probably very academic:

3. If some package being built for armhf needs zsh:any,
   because the build scripts are for zsh, that would work
   then.

#808977 was the simplest/safest first move:
- It's very straight forward / easy to explain
- it can't break anything, really
- Solves (1) and (2) for those cases, where zsh is
  installed on its own and not as a dependency of z-sy-h or
  something else.


Tagging zsh is a more complex story, as we now see. That's,
why I haven't included it in the first move.
For zsh itself there are three options, IMHO:

a) Stay, where it is. Very safe. Already allows some
   flexibility, as outlined above. But wouldn't allow
   z-sy-h + zsh:x32

b) Go the bash-way: Declare zsh as "foreign", basicly
   saying that it only has an interpreter interface to all
   of its users. If there are no binary extensions out
   there, then that is entirely possible, and maybe even
   the best option. But I don't know, if binary extensions
   do exist?

c) Go the python way: This is in the middle. Declare zsh
   as m-a-allowed. This says:
   - If you don't know, go for (a).
   - If you know (like z-sy-h), you can opt in for (b).
   That's why I proposed this one. It should be quite safe
   and still allow flexibility.


To summarize:
- Please keep zsh-common as m-a-foreign!
- Consider (c)

Thanks for all your work and care for zsh, it's highly
appreciated!


> 		Regards, Axel

Cheers

Elrond