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