1 |
On Tue, Jun 29, 2010 at 8:14 AM, Dale <rdalek1967@×××××.com> wrote: |
2 |
> Mark Knecht wrote: |
3 |
>> |
4 |
>> On Mon, Jun 28, 2010 at 10:12 AM, Mark Knecht<markknecht@×××××.com> |
5 |
>> wrote: |
6 |
>> |
7 |
>>> |
8 |
>>> On Mon, Jun 28, 2010 at 9:55 AM,<meino.cramer@×××.de> wrote: |
9 |
>>> |
10 |
>>>> |
11 |
>>>> Hi, |
12 |
>>>> |
13 |
>>>> is it possible to emerge all missing dependencies of a certain |
14 |
>>>> application without emerging the application itself? And: Will |
15 |
>>>> I hurt the system that way? |
16 |
>>>> |
17 |
>>>> Best regards, |
18 |
>>>> mcc |
19 |
>>>> |
20 |
>>> |
21 |
>>> ??? |
22 |
>>> |
23 |
>>> emerge -DuN application |
24 |
>>> |
25 |
>>> ??? |
26 |
>>> |
27 |
>>> What am I missing in the question? |
28 |
>>> |
29 |
>>> Test it on a clean app with no dependencies missing. It should emerge |
30 |
>>> nothing. Then emerge -C one dependency and try it again. It should |
31 |
>>> pick up that dependency but not emerge the app itself. |
32 |
>>> |
33 |
>>> You will not hurt your system doing that command. |
34 |
>>> |
35 |
>>> - Mark |
36 |
>>> |
37 |
>>> |
38 |
>> |
39 |
>> I wanted to follow up on my somewhat cavalier comment a couple of days |
40 |
>> ago about doing emerge -C on a dependency. It was a bad comment for me |
41 |
>> to make without adding some discussion around it. This can actually |
42 |
>> harm your system if you emerge -C the wrong dependency. For instance, |
43 |
>> emerge -C gcc or python is likely a bad thing to do as you will be |
44 |
>> unable to build anything to get the system fixed again. However emerge |
45 |
>> -C jack-audio-connection-kit as a dependency for something like Ardour |
46 |
>> wouldn't harm the system but would demonstrate what I was talking |
47 |
>> about. |
48 |
>> |
49 |
>> Any new user reading this thread at some future date should ensure |
50 |
>> that (at a minimum) if they emerge -C anything at all that at least |
51 |
>> it's not part of @system. emerge should warn of this but it's best to |
52 |
>> do a little study before pushing the enter key. |
53 |
>> |
54 |
>> Cheers, |
55 |
>> Mark |
56 |
>> |
57 |
>> |
58 |
> |
59 |
> It is good that you explained that more. I thought about the same thing but |
60 |
> thought maybe I was missing something that was mentioned earlier in another |
61 |
> message. |
62 |
> |
63 |
> I wouldn't always count on portage warning before removing a system package |
64 |
> tho. I tested this by trying to remove python and portage said nothing it |
65 |
> doesn't say on any other package even one in the world file. Future users |
66 |
> may want to ask first either here or on the forums before removing something |
67 |
> that may be questionable. |
68 |
> |
69 |
> It may not be a bad idea for a thread with packages that should never be |
70 |
> removed. Things such as gcc, python, baselayout etc. Maybe a user would |
71 |
> find that and at least have a general guide. I also think it would be a |
72 |
> good idea to have the same on the forums as a "sticky" thread that the mods |
73 |
> can edit from time to time. |
74 |
> |
75 |
> Dale |
76 |
|
77 |
Dale, |
78 |
The last thing I want to do is cause anyone any trouble. From that |
79 |
point it's easier to just stay quiet all the time and let others more |
80 |
experienced than myself answer all the questions. However I don't |
81 |
really want to act that way - taking and never giving. |
82 |
|
83 |
I like your idea about lists of packages that should never be |
84 |
removed. Personally I think a doc doc page somewhere in the |
85 |
install/maintenance doc group would be good but it would need to be |
86 |
well maintained. Understanding the absolute minimum number of things |
87 |
that are required to use emerge and get a package built would be a |
88 |
good doc, if it doesn't exist somewhere already. |
89 |
|
90 |
Personally I'm never 100% sure about anything that's not an |
91 |
application package I installed myself and is sitting in the world |
92 |
file. I suspect others - possibly you included - have similar fears at |
93 |
times. |
94 |
|
95 |
Cheers, |
96 |
Mark |