just for the record: > > $ sudo apt-cache show python3 > > Package: python3 > > .... > > Provides: python3-profiler > > > > $ sudo apt-cache showpkg python3 > > ... > > Provides: > > 3.5.3-1 - python3-profiler:i386 (= ) python3:any (= 3.5.3-1) > > python3-profiler > > (= ) python3-profiler:any (= ) > > > > I cant make sense of all those 'virtual' packages: > > python3-profiler:i386 (= ) python3:any (= 3.5.3-1) python3-profiler (= ) > > python3-profiler:any (= ) > > > > The control file of python3_3.5.3-1_amd64.deb outputs only: > > Provides: python3-profiler > > > > Obviously those 'produced' Provides values declare sth related to > > architectures.But i dont > > understand the logic. > > They are an implementation detail concerning Multi-Arch, the package is > Multi-Arch: same.
python3 is M-A: allowed – so M-A: foreign via explicit opt-in. If another package accepts any architecture of python3 to satisfy the dependency it depends on "python3:any" while "python3" means the architecture of the current dependency chain. That is so as this (and a few other packages) carry two parts: An interpreter working with files and a module interface loading architecture specific binary modules. Look for "interpreter problem" if you are interested in details. Back then I decided on how to implement M-A it seemed best to reuse existing implementations via provides: All apt clients kept working by "translating" Multi-Arch into the preexisting relationship structure with some additional internal provides, conflicts and co sprinkled in. I still thing that was a good idea, but the downside is that in debug output (and showpkg is very close to debug output) they will appear and initially be confusing – but after a while they make sense… I hope. Best regards David Kalnischkies
signature.asc
Description: PGP signature
