On Sun, Nov 20, 2005 at 11:50:55PM +0000, Joerg Sommer wrote: > Steve Langasek <vorlon@debian.org> wrote: > > On Sun, Nov 20, 2005 at 10:23:58AM +0000, Joerg Sommer wrote: > >> I've got a bug report (#336527) my package bootchart-view do not work > >> with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a > >> packages that is not in Debian? But if it do not work with j2re1.3 it > >> should more than ever not work with older version. But I would assume > >> older version have different packages names. So I must add a list of > >> packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the > >> version clause (j2re1.3 (<< 1.3)). So what should I do? > > "Does not work with j2re1.3" means you should be depending on what it *does* > > work with, not trying to conflict with (unrelated) packages that don't > > satisfy the dependency. > All packages in Debian they provide java-virtual-machine work with > bootchart-view. That includes jamvm and gij-3.3? > But all alternative JVMs do only work with svg output and only Sun's JVM > support png. This is the reason, why I don't want restrict the > dependencies upon the JVMs in Debian. I don't understand this explanation at all. The bug report is about a failure due to class version mismatches; what does this have to do with svg vs. png? > > The problem here is that bootchart-view depends on '| java-virtual-machine', > > which does not satisfy its runtime needs. Depend on something more > > appropriate; possibly even j2re1.4. > I can not find this package The implication was that j2re1.4 would be a virtual package, provided by those packages which implement the 1.4 spec. But of course, there's also a *real* j2re1.4 package, not available in Debian but buildable using java-package. The main point is not that j2re1.4 is the correct name to include in this list (it may be, but I don't know that for sure); the point is that java-virtual-machine is *incorrect*, because j-v-m only ensures you a lowest common denominator feature set, and that's obviously not sufficient in this case. > Can I depend on packages they are not in Debian? This would be new to me. In a list of alternatives, sure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature