[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to deal with dependencies/conflics on third party packages

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

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

> 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

Reply to: