[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture



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.gello@gmail.com
> 
> Skype: vasek.gello
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
> 
> 
> 16 жовтня 2021 р. 16:58:34 UTC, Vasyl Gello <vasek.gello@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.gello@gmail.com
> > 
> > Skype: vasek.gello
> > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
> > 
> > 16 жовтня 2021 р. 16:22:09 UTC, Helmut Grohne <helmut@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
> > > 



Reply to: