On Fri, 2017-10-13 at 00:39 -0400, Afif Elghraoui wrote: > > على الخميس 12 تشرين الأول 2017 01:48، كتب Adam D. Barratt: > > The britney log says: > > > > trying: canu > > skipped: canu (0, 2975, 79) > > got: 43+0: a-4:i-26:a-2:a-1:a-1:m-1:m-4:m-1:p-1:s-2 > > * arm64: canu > > > > Which indicates that the binary package "canu" would be > > uninstallable > > on (at least) arm64 were the package to migrate. A little > > investigation > > leads to this being due to the dependency on "mhap", which in turns > > depends on "libssw-java", and: > > > > libssw-java | 1.1-1+b1 | testing | amd64 > > libssw-java | 1.1-1+b1 | unstable | amd64, kfreebsd- > > amd64 > > > > This also means that your package has an unreported RC bug in > > unstable > > right now, as it cannot possibly be installable on any > > architectures > > other than amd64 and kfreebsd-amd64. > > Thanks for the explanation. > > libssw uses some x86-specific processor features if I remember > correctly. Is it not possible to depend on it without incurring an RC > bug?
Yes, trivially - by depending on it only on architectures where it actually exists. Your problem is that e.g. your armel packages end up depending on a package that only exists on amd64. Your realistic options depend on how strongly canu requires mhap (can it work without it on non-amd64 architectures?), and how strongly mhap requires libssw (again, can it work without it on other architctures?). Regards, Adam
