Kevin O'Gorman schreef:
> Synopsis: I do have java 1.5 unmasked. I need it for the classes I
> teach. So why doesn't db use java 1.5?
>
> On 12/31/05, Holly Bostick <[EMAIL PROTECTED]> wrote:
>
>> Jason Stubbs schreef:
>>
>>> On Saturday 31 December 2005 21:57, Holly Bostick wrote:
>>>
>>>
>>>> If you look at the output
>>>>
>>>>
>>>>
>>>>> [nomerge ] sys-libs/db-4.2.52_p2-r1 -bootstrap +doc
>>>>> +java -nocxx +tcltk
>>>>
>>>> the reason db is calling for java is because you have the
>>>> "java" USE flag set for db.
>>>>
>>>> Do you really need db to use Java? If not, disable the flag (#
>>>> echo 'sys-libs/db -java' >>/etc/portage/package.use); problem
>>>> solved.
>>>
>>>
>>> All the way up until the next package which depends on java. Only
>>> the first package that is came across is listed as the parent.
>>> sys-libs/db doesn't call for any specific version of java. The
>>> complaint is that sun-jdk-1.5 is installed but emerge is wanting
>>> to install sun-jdk-1.4. This indicates that sun-jdk-1.5 is likely
>>> masked.
>>>
>>
>> Well that's all true, Jason, but my point was that this is an
>> *option*, not a hard dependency, and many times people have USE
>> flags enabled for things they don't even need (or need for the
>> specific program).
>>
>> So Kevin certainly could unmask sun-jdk 1.5 --and if it's
>> installed, then how did that happen without it being unmasked?
>> Sun-jdk-1.5 is hard-masked! The original post does not say that any
>> version of the jdk is actually installed:
>>
>>
>>> Anyway, my latest emerge world failed because of sun-jdk-1.4.2.10
>>> (!!!). The current one is 1.5 something.
>>
>> Meaning (to me) that Kevin is referring to the current *available*
>> *version* of sun-jdk, not to any version he might have installed
>> (and my impression is that he does not in fact have any version of
>> sun-jdk installed), and he's just concerned that an "out-of-date"
>> version will be installed rather than the latest.
>>
>> But if he doesn't need java support in the db at all, then
>> disabling the USE flag entirely (globally or for this package
>> alone), then java won't be called by the emerge of db, which saves
>> having to unmask a package that Kevin may have concerns about
>> installing in the first place if he runs stable, or even unstable--
>> sun-jdk-1.5 *is* hard-masked, after all, and one should rightfully
>> think twice and then think again about installing a hard-masked
>> package-- and secondly does not install bloat onto the system (if
>> he doesn't need java support in db, then he has no reason to
>> install it, or spend the extra compile time installing db java
>> support).
>>
>> I've often solved similar issues on my own system by the simple
>> expedient of disabling the USE flag that was calling the dependency
>> that was giving me a problem. Helps keep the system clean.
>
>
>
> This has been pretty informative. Perhaps I'm getting closer to
> understanding this.
>
> Fact: I do have Java 1.5 unmasked. I teach java, and need to be
> using the current version. I have the java USE flag on generally, so
> there will probably be a number of packages that will call for it.
> On the other hand, I don't have a specific need for it in 'db' which
> I never use explicitly -- I use gdbm or one of the SQL products for
> what database stuff I do personally.
>
> The question now seems to be: why doesn't db use Java 1.5? Watching
> the emerge go by, it seemed to be doing just that -- the filenames
> were all 1.5. However, it's not just db. When I disable java in db
> using package.use, the problem just switches to another dependency
> path:
>
> [nomerge ] dev-lang/swig-1.3.21 +X +doc +guile
> +java +perl -php +python +ruby +tcltk [ebuild NSF ]
> dev-java/sun-jdk-1.4.2.10 +X +alsa -browserplugin +doc -examples
> -jce +mozilla +nsplugin 35,592 kB
Quite possibly because the issue may be in your virtuals rather than in
the world file:
Runtime Dependencies
swig-1.3.27
<snip>
java virtual/jdk
I presume that db (among others) also relies on virtual/jdk rather than
an explicit package or package version).
And iirc, the virtual is not going to be linked to a hard-masked package
(or at least it most likely is not atm, or the hard-masked packages are
listed after the stable packages).
So what I would do is check /var/cache/edb/virtuals and see what the
listing for jdk actually is.
IIrc, mine now reads
virtual/jdk dev-java/sun-jdk dev-java/blackdown-jdk
because I manually reversed sun-jdk and blackdown-jdk; otherwise
everything that relied on virtual/jdk kept trying to install blackdown,
which I don't want.
And may I ask, when you say that you have sun-jdk unmasked, you mean
both in package.unmask and in package.keywords, right? Because it not
being unmasked in package.keywords (as well as disabling the hard mask
in package.unmask) is the only reason I can think of that only the
stable version is coming up (since clearly swig, for example, is
recognizing that sun-jdk is the preferred virtual/jdk as opposed to all
the other java jdks that are available, but does not recognize the
unstable versions thereof).
Anyway, a bit confused, but I hope it's helpful.
Holly
--
gentoo-user@gentoo.org mailing list
