Re: inconsistent versions of M-A: same packages
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
Reply to: