Hi, Quoting Ralf Treinen (2014-11-09 18:05:15) > But this does only one co-installability check at a time, right ?
correct, this makes your solution the better choice. > Anyway, the script is very simple (attached). Nifty! I didn't know that dose-debcheck can read from stdin! > The raw result of a run for amd64 together with i386 can be found at [1]. > What one can see from a cursery inspection of that result : > > We have 4415 MA=same packages that exist both in amd and i386 (main/sid). > I didn't expect it to be that many. > > 1033 of them are not co-installable. > > Where they are not co-installable, the reason seems mostly to be that > the packages have dependencies which are not MA-enabled. The first case in > the list, for instance: > > audacious-dbg-pseudo is MA=same but depends on audacious which is MA=no. On top of that it seems that there are many instances where the reason for a package not being co-installable is a package from the same source package. Thus, it would probably be very helpful to generate this information regularly and display in the pts/tracker if a package makes another one un-co-installable. Here some quick results of why packages are not co-installable: Missing: >>> import yaml >>> from collections import Counter >>> d = yaml.load(open("out")) >>> Counter([p['reasons'][0].get('missing', >>> {'pkg':{'unsat-dependency':0}})['pkg']['unsat-dependency'] for p in >>> d['report']]) Gives as the top 10: [unsat dependency] [X times encountered] ttf-bitstream-vera 22 dh-python 18 poppler-data (>= 0.4.5-3~) | gs-cjk-resource 16 augeas-lenses 15 libgsf-1-common (>= 1.14.30-2) 9 lxmenu-data 8 openmpi-common (= 1.6.5-9) 6 krb5-config 4 vlc-plugin-pulse 4 gnat 3 From a purely dependency point of view, the above would be solved by making the packages depended upon by the first column Multi-Arch:foreign. Of course this is not the technically correct solution in many cases. Conflict: >>> Counter([p['reasons'][0].get('conflict', >>> {'pkg1':{'package':0}})['pkg1']['package'] for p in d['report']]) Gives as the top 10: [packages] [makes X packages not co-installable] perl-base 147 libtbb2 43 libglib2.0-dev 35 libglu1-mesa-dev 32 libatlas3-base 24 liblog4cpp5 22 libboost1.54-dev 21 libevdev2 20 libopenmpi1.6 14 libgupnp-1.0-4 13 From a purely dependency point of view, the above would be solved by making the packages in the first column Multi-Arch:same. Of cource this is not the technically correct solution in many cases. Incidentally, I was just producing very similar results in the realm of crossbuild satisfiability today. Unsurprisingly, the results look very similar to the above. I posted a message about this to the debian-cross list today: https://lists.debian.org/20141109152937.6173.82192@hoothoot The important links from that message: 1. http://bootstrap.debian.net/cross.html (regenerated daily with 550 source packages) 2. https://mister-muffin.de/p/Lc4-.html (static but all of sid) 3. https://mister-muffin.de/p/xOJO.html (static and package selection as in 1. but multiple reasons) The two sections in all three above links are also "Missing" and "Conflicts", just as I made the destinction above with Ralf's results. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110000009.6173.73845@hoothoot