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

Re: [Fwd: Bug#291946: freemind: Installs with java1.3 but won't works]



On Thu, Jan 27, 2005 at 09:03:08PM +0100, Eric Lavarde wrote:
> new maintainer, I've got the below bug report.
> I'm a bit perplex here:
> - my current Depends is "Depends: j2re1.4 | java2-runtime, j2re1.4 | 
> java-virtual-machine"
> - can I put a version dependency on a virtual package? (does then the 
> version come from the version of the real package to which the virtual 
> one is attached?)
> - if no, what should I do?
> - if yes, should I put it on java2-runtime, on java-virtual-machine or 
> on both?

> or to make it more direct, should I change my "Depends" to:
> A) Depends: j2re1.4 | java2-runtime (>> 1.4), j2re1.4 | 
> java-virtual-machine (>> 1.4)
> B) Depends: j2re1.4 | java2-runtime (>> 1.4), j2re1.4 | java-virtual-machine
> B) Depends: j2re1.4 | java2-runtime, j2re1.4 | java-virtual-machine (>> 1.4)
> C) something else (precise)
> D) nothing to do, forget about it...

> Ah, ah, going through the policy, I find (7.4 Virtual packages):
> --- BEGIN ---
> If a dependency or a conflict has a version number attached then only 
> real packages will be considered to see whether the relationship is 
> satisfied (or the prohibition violated, for a conflict) - it is assumed 
> that a real package which provides the virtual package is not of the 
> "right" version. So, a Provides field may not contain version numbers, 
> and the version number of the concrete package which provides a 
> particular virtual package will not be looked at when considering a 
> dependency on or conflict with the virtual package name.
> 
> It is likely that the ability will be added in a future release of dpkg 
> to specify a version number for each virtual package it provides. This 
> feature is not yet present, however, and is expected to be used only 
> infrequently.
> --- END ---

> Does this mean, answer D above is the right one!?

No, it means your current dependencies are *broken*, because the runtime
requirements of your package are more specific than the meaning of the
virtual package java2-runtime.  This means you cannot use java2-runtime as
an alternative in your dependency list.

Ideally, the java maintainers would provide a virtual package meaning
"j2re1.4 or better" (as well as one meaning "j2re1.5 or better") that you
could use as an alternative.  Barring that, your only choices are to list
all the existing alternatives one by one, or to remove the alternative
completely and just depend on j2re1.4 (which is much uglier for users).

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: