1 |
Kevin O'Gorman schreef: |
2 |
> Synopsis: I do have java 1.5 unmasked. I need it for the classes I |
3 |
> teach. So why doesn't db use java 1.5? |
4 |
> |
5 |
> On 12/31/05, Holly Bostick <motub@××××××.nl> wrote: |
6 |
> |
7 |
>> Jason Stubbs schreef: |
8 |
>> |
9 |
>>> On Saturday 31 December 2005 21:57, Holly Bostick wrote: |
10 |
>>> |
11 |
>>> |
12 |
>>>> If you look at the output |
13 |
>>>> |
14 |
>>>> |
15 |
>>>> |
16 |
>>>>> [nomerge ] sys-libs/db-4.2.52_p2-r1 -bootstrap +doc |
17 |
>>>>> +java -nocxx +tcltk |
18 |
>>>> |
19 |
>>>> the reason db is calling for java is because you have the |
20 |
>>>> "java" USE flag set for db. |
21 |
>>>> |
22 |
>>>> Do you really need db to use Java? If not, disable the flag (# |
23 |
>>>> echo 'sys-libs/db -java' >>/etc/portage/package.use); problem |
24 |
>>>> solved. |
25 |
>>> |
26 |
>>> |
27 |
>>> All the way up until the next package which depends on java. Only |
28 |
>>> the first package that is came across is listed as the parent. |
29 |
>>> sys-libs/db doesn't call for any specific version of java. The |
30 |
>>> complaint is that sun-jdk-1.5 is installed but emerge is wanting |
31 |
>>> to install sun-jdk-1.4. This indicates that sun-jdk-1.5 is likely |
32 |
>>> masked. |
33 |
>>> |
34 |
>> |
35 |
>> Well that's all true, Jason, but my point was that this is an |
36 |
>> *option*, not a hard dependency, and many times people have USE |
37 |
>> flags enabled for things they don't even need (or need for the |
38 |
>> specific program). |
39 |
>> |
40 |
>> So Kevin certainly could unmask sun-jdk 1.5 --and if it's |
41 |
>> installed, then how did that happen without it being unmasked? |
42 |
>> Sun-jdk-1.5 is hard-masked! The original post does not say that any |
43 |
>> version of the jdk is actually installed: |
44 |
>> |
45 |
>> |
46 |
>>> Anyway, my latest emerge world failed because of sun-jdk-1.4.2.10 |
47 |
>>> (!!!). The current one is 1.5 something. |
48 |
>> |
49 |
>> Meaning (to me) that Kevin is referring to the current *available* |
50 |
>> *version* of sun-jdk, not to any version he might have installed |
51 |
>> (and my impression is that he does not in fact have any version of |
52 |
>> sun-jdk installed), and he's just concerned that an "out-of-date" |
53 |
>> version will be installed rather than the latest. |
54 |
>> |
55 |
>> But if he doesn't need java support in the db at all, then |
56 |
>> disabling the USE flag entirely (globally or for this package |
57 |
>> alone), then java won't be called by the emerge of db, which saves |
58 |
>> having to unmask a package that Kevin may have concerns about |
59 |
>> installing in the first place if he runs stable, or even unstable-- |
60 |
>> sun-jdk-1.5 *is* hard-masked, after all, and one should rightfully |
61 |
>> think twice and then think again about installing a hard-masked |
62 |
>> package-- and secondly does not install bloat onto the system (if |
63 |
>> he doesn't need java support in db, then he has no reason to |
64 |
>> install it, or spend the extra compile time installing db java |
65 |
>> support). |
66 |
>> |
67 |
>> I've often solved similar issues on my own system by the simple |
68 |
>> expedient of disabling the USE flag that was calling the dependency |
69 |
>> that was giving me a problem. Helps keep the system clean. |
70 |
> |
71 |
> |
72 |
> |
73 |
> This has been pretty informative. Perhaps I'm getting closer to |
74 |
> understanding this. |
75 |
> |
76 |
> Fact: I do have Java 1.5 unmasked. I teach java, and need to be |
77 |
> using the current version. I have the java USE flag on generally, so |
78 |
> there will probably be a number of packages that will call for it. |
79 |
> On the other hand, I don't have a specific need for it in 'db' which |
80 |
> I never use explicitly -- I use gdbm or one of the SQL products for |
81 |
> what database stuff I do personally. |
82 |
> |
83 |
> The question now seems to be: why doesn't db use Java 1.5? Watching |
84 |
> the emerge go by, it seemed to be doing just that -- the filenames |
85 |
> were all 1.5. However, it's not just db. When I disable java in db |
86 |
> using package.use, the problem just switches to another dependency |
87 |
> path: |
88 |
> |
89 |
> [nomerge ] dev-lang/swig-1.3.21 +X +doc +guile |
90 |
> +java +perl -php +python +ruby +tcltk [ebuild NSF ] |
91 |
> dev-java/sun-jdk-1.4.2.10 +X +alsa -browserplugin +doc -examples |
92 |
> -jce +mozilla +nsplugin 35,592 kB |
93 |
|
94 |
Quite possibly because the issue may be in your virtuals rather than in |
95 |
the world file: |
96 |
|
97 |
Runtime Dependencies |
98 |
swig-1.3.27 |
99 |
<snip> |
100 |
java virtual/jdk |
101 |
|
102 |
|
103 |
I presume that db (among others) also relies on virtual/jdk rather than |
104 |
an explicit package or package version). |
105 |
|
106 |
And iirc, the virtual is not going to be linked to a hard-masked package |
107 |
(or at least it most likely is not atm, or the hard-masked packages are |
108 |
listed after the stable packages). |
109 |
|
110 |
So what I would do is check /var/cache/edb/virtuals and see what the |
111 |
listing for jdk actually is. |
112 |
|
113 |
IIrc, mine now reads |
114 |
|
115 |
virtual/jdk dev-java/sun-jdk dev-java/blackdown-jdk |
116 |
|
117 |
because I manually reversed sun-jdk and blackdown-jdk; otherwise |
118 |
everything that relied on virtual/jdk kept trying to install blackdown, |
119 |
which I don't want. |
120 |
|
121 |
And may I ask, when you say that you have sun-jdk unmasked, you mean |
122 |
both in package.unmask and in package.keywords, right? Because it not |
123 |
being unmasked in package.keywords (as well as disabling the hard mask |
124 |
in package.unmask) is the only reason I can think of that only the |
125 |
stable version is coming up (since clearly swig, for example, is |
126 |
recognizing that sun-jdk is the preferred virtual/jdk as opposed to all |
127 |
the other java jdks that are available, but does not recognize the |
128 |
unstable versions thereof). |
129 |
|
130 |
Anyway, a bit confused, but I hope it's helpful. |
131 |
|
132 |
Holly |
133 |
-- |
134 |
gentoo-user@g.o mailing list |