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[1]. 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 [1] Technically, the rule is "must not increase the number of uninstallable packages in testing"
signature.asc
Description: Digital signature
