On Sat, Oct 16, 2021 at 04:58:34PM +0000, Vasyl Gello wrote: > >If you don't like removing > >Multi-Arch: foreign from kodi-data, there is another way out: Move the > >python modules to a new kodi-python-addons package. Move the relevant > >python dependencies to this package. Make it Architecture: any (not > >all). It can become Multi-Arch: same, but that won't help much. Any user > >of it must depend on kodi-python-addons directly. A dependency from > >kodi-data to kodi-python-addons is not sufficient (as kodi-data is > >supposed to remain Multi-Arch: foreign). > > This is what I want to do!
Great. > However, this points to another drawback: we can not propagate modified > packages to > stable and oldstable-bpo. So I guess removing "Multi-Arch: foreign" is better > for 19.x > and for 20.x I am going to implement the refactored scheme of packages. Why would you want to do that? stable releases do have bugs and unless they're severe, we don't usually fix them. The M-A:foreign annotation poses the risk of providing an installation set that does not actually work, but the conflict on python3-pycryptodome largely prevents that from happening practice. So why do you care about stable here? > Is that OK to just drop "m-a: foreign" from kodi-data:all or I need something > more to fix? As a short-term-fix that's certainly a good thing to d. For longer term, the kodi-python-addons (or however you call it) solution would be better. Still, we'll need to figure out what to do about the conflict arising from samba-libs to make this practically useful. Helmut
