On Sat, 2021-10-16 at 17:29 +0000, Vasyl Gello wrote: > Hi Adam! > > CC'ing you because I would like to understand if removing "m-a: > foreign" from kodi-data might affect dependency resokution on stable. >
I'm not really sure what you're asking here. The effect on dependency resolution on a stable system would be exactly the same as on an unstable system. As to what those effects are in practice, I suspect Helmut has already looked into the details of that as it applies to this package. In general we'd probably need some convincing that changing M-A qualifiers in a stable update was appropriate, but that doesn't stop you making the change in unstable. Regards, Adam > I really hope it will not put a roadblock to future Kodi 19.x updates > in stable :) > -- > Vasyl Gello > Certified SolidWorks Expert > > Mob.:+380 (98) 465 66 77 > > E-Mail: vasek.ge...@gmail.com > > Skype: vasek.gello > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 > > > 16 жовтня 2021 р. 16:58:34 UTC, Vasyl Gello <vasek.ge...@gmail.com> > написав(-ла): > > Hi Helmut! > > > > > I vaguely guess that we're in case b) here. > > > > You are absolutely correct! Kodi data package hosts code which is > > executed by Kodi binary and > > it depends on python3:any. > > > > > 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! > > > > 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. > > > > Is that OK to just drop "m-a: foreign" from kodi-data:all or I need > > something more to fix? > > -- > > Vasyl Gello > > Certified SolidWorks Expert > > > > Mob.:+380 (98) 465 66 77 > > > > E-Mail: vasek.ge...@gmail.com > > > > Skype: vasek.gello > > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 > > > > 16 жовтня 2021 р. 16:22:09 UTC, Helmut Grohne <hel...@subdivi.de> > > написав(-ла): > > > Hi, > > > > > > I think this bug has been diverted to being able to use > > > widevinecdm. > > > While that turns the original request a little academic, there > > > still is > > > a bug there. > > > > > > On Sat, Oct 16, 2021 at 02:07:19PM +0200, Justus Winter wrote: > > > > 13:37 <teythoon> but, kodi-data (which is ma: foreign) depends > > > > on > > > > python3-pycryptodome which contains architecture- > > > > dependent code > > > > aiui > > > > > > This raises the question of why kodi-data depends on > > > python3-pycryptodome. There are basically two reasonable answers: > > > > > > a) It provides programs (something you can run from a shell) that > > > happen > > > to use python3-pycryptodome. In this case, kodi-data also must > > > depend > > > on a python3 interpreter. > > > > > > b) It provides python modules that use python3-pycryptodome (to > > > be > > > imported by other packages). In this case, kodi-data must not > > > be > > > marked Multi-Arch: foreign. > > > > > > So regardless of the widevinecdm issue, this is a bug in kodi- > > > data. > > > > > > Now this all doesn't solve the problem of foreign installation, > > > but we > > > can only really think about that once we have correct metadata. > > > > > > Once it has been fixed and a week has passed, we should look into > > > https://bootstrap.debian.net/foreign_install/kodi.html. It gives > > > a good > > > overview of the outstanding metadata issues. > > > > > > I hope this makes sense to you. If it does not, please don't > > > hesitate to > > > ask. > > > > > > Helmut > > >