On Sun, May 02, 2004 at 06:01:36PM -0400, Grzegorz B. Prokopski wrote: > On (02/05/04 21:56), Matthias Klose wrote: > > Steve Langasek writes: > > > So the issue is that libsablevm-native1 is built on all architectures, > > > but sablevm hasn't been built on mips and mipsel, resulting in an > > > unsatisfiable dependency. > agrh... now i remember - I tightened the inter-dependencies to disallow > partial upgrades, that is - when you upgrade sablevm but not the java > library (which consists of two: one native and one pure-java packages). Are there concrete reasons why partial upgrades must not be allowed? > > It's the build dependency on libffi2-dev, which is still missing on > > mips/mipsel. If/when gcc-3.4 moves to unstable, libffi will be > > available on all architectures. > Good point. By the time we release 1.1.5 (we're at 1.1.3 now) this > problem will be solved one way or another. I'll try to figure something > out on our own so that we didn't have to bother you every single time > in longer term. Now I have much better overview of what's happening. > Meanwhile - could you please KICK SableVM 1.1.3 to go into testing? I don't have that power, sorry. The testing scripts will only let a package in when all of the binary packages it creates are up-to-date on all architectures, and all of the binary packages are installable using just those packages that are already in testing. This means you must solve the problem of uninstallable libsablevm-native1 packages on mips and mipsel before it can get into testing, either by having an ftp-master remove those binary packages or by fixing the problem that keeps them from being uninstallable. -- Steve Langasek postmodern programmer  Technically, the rule is "must not increase the number of uninstallable packages in testing"
Description: Digital signature