1 |
Alan McKinnon wrote: |
2 |
> On Sunday 24 May 2009 11:28:30 Neil Bothwick wrote: |
3 |
> |
4 |
>> On Sun, 24 May 2009 11:07:13 +0200, Alan McKinnon wrote: |
5 |
>> |
6 |
>>>> Portage is not in system, only the virtual. That can be |
7 |
>>>> satisfied by Paludis, which does not need Python. |
8 |
>>>> |
9 |
>>> Lucky for you, I know your sense of humour by now :-) |
10 |
>>> |
11 |
>>> Doesn't help portage users though, and portage is still the default |
12 |
>>> package manager on Gentoo. I don't see that changing any time soon, if |
13 |
>>> ever. |
14 |
>>> |
15 |
>>> Besides, unless you do it manually, you need portage to install |
16 |
>>> paludis, right? Without python, you don't get paludis. |
17 |
>>> |
18 |
>>> Either way, it's a bug. portage supports inheriting multiple parent |
19 |
>>> profiles. One approach would be to add a new collection of profiles in |
20 |
>>> addition to the existing base/, default/ and targets/ - called say |
21 |
>>> pkgmgr. |
22 |
>>> |
23 |
>> Is it really a bug? Postage is the default for the virtual and it depends |
24 |
>> on python, so there is no need for python itself to be in @system. This |
25 |
>> doesn't cause any problems except the one Dale mentions, which is that |
26 |
>> FEATURES=buildsyspkg does not build a package for python. man make.conf |
27 |
>> describes this option as "Build binary packages for just packages in the |
28 |
>> system set. Which is accurate but maybe not the desired behaviour. The |
29 |
>> option should really by to build packages for packages in @system and |
30 |
>> their dependencies. Put another way, build all the packages necessary to |
31 |
>> run "emerge -eK @system". |
32 |
>> |
33 |
>> I'd suggest filing an enhancement request on b.g.o. |
34 |
>> |
35 |
> |
36 |
> Using the "this is very unexpected behaviour" definition of bug, I certainly |
37 |
> do call it a bug. All three of the following commands, produce the same end |
38 |
> result (a b0rked system), but are treated very differently. I my mind, delete |
39 |
> warnings should be handled the same as installs, by taking the entire dep tree |
40 |
> into account: |
41 |
> |
42 |
> alan@nazgul ~ $ sudo emerge -avC python |
43 |
> Password: |
44 |
> |
45 |
> |
46 |
>>>> These are the packages that would be unmerged: |
47 |
>>>> |
48 |
> |
49 |
> dev-lang/python |
50 |
> selected: 2.5.4-r2 2.6.2 |
51 |
> protected: none |
52 |
> omitted: none |
53 |
> |
54 |
> |
55 |
>>>> 'Selected' packages are slated for removal. |
56 |
>>>> 'Protected' and 'omitted' packages will not be removed. |
57 |
>>>> |
58 |
> |
59 |
> Would you like to unmerge these packages? [Yes/No] n |
60 |
> |
61 |
> Quitting. |
62 |
> |
63 |
> alan@nazgul ~ $ sudo emerge -avC portage |
64 |
> |
65 |
> |
66 |
>>>> These are the packages that would be unmerged: |
67 |
>>>> |
68 |
> * Not unmerging package sys-apps/portage-2.2_rc33 since there is no valid |
69 |
> * reason for portage to unmerge itself. |
70 |
> |
71 |
> |
72 |
>>>> No packages selected for removal by unmerge |
73 |
>>>> |
74 |
> alan@nazgul ~ $ sudo emerge -avC gcc |
75 |
> |
76 |
> |
77 |
>>>> These are the packages that would be unmerged: |
78 |
>>>> |
79 |
> |
80 |
> |
81 |
> !!! 'sys-devel/gcc' is part of your system profile. |
82 |
> !!! Unmerging it may be damaging to your system. |
83 |
> |
84 |
> |
85 |
> sys-devel/gcc |
86 |
> selected: 4.3.3-r2 |
87 |
> protected: none |
88 |
> omitted: none |
89 |
> |
90 |
> |
91 |
>>>> 'Selected' packages are slated for removal. |
92 |
>>>> 'Protected' and 'omitted' packages will not be removed. |
93 |
>>>> |
94 |
> |
95 |
> Would you like to unmerge these packages? [Yes/No] n |
96 |
> |
97 |
> Quitting. |
98 |
> |
99 |
> I'll file a feature request |
100 |
> |
101 |
> |
102 |
|
103 |
+1 |
104 |
|
105 |
All I know is this: |
106 |
|
107 |
1: If I accidentally remove python, portage will not say a word as far |
108 |
as warning me this is bad. This is what got the OP into this. If he |
109 |
had this warning, he may not have done this. Prevention is the best way |
110 |
but even that doesn't work. |
111 |
|
112 |
2: Once #1 happens, your pretty much screwed because you don't even |
113 |
have a binary backup even tho it is set in make.conf to have one. That |
114 |
was the reason I put that setting in make.conf but someone chose to |
115 |
screw with my setting and its meaning. I guess now buildpkg is my only |
116 |
option. It's the only way to insure I can recover if I make a boo boo. |
117 |
|
118 |
3: Portage is the package manager for Gentoo. As Alan said, it always |
119 |
has been and most likely always will. I'm not against having other |
120 |
package managers but if they are going to start messing up my settings, |
121 |
then I plan to gripe at least a little. If they are not going to |
122 |
support buildsyspkg then it needs to be announced and removed. False |
123 |
security is worse than none at all. |
124 |
|
125 |
My opinion on how this SHOULD work. If I do a emerge -e system, every |
126 |
package it builds should have a binary saved for back up. It doesn't |
127 |
matter if it is a dependency on something else or not, it should be |
128 |
built and stored. That was the purpose of that. |
129 |
|
130 |
Dale is going to go change this to buildpkg and run emerge -e system. |
131 |
Let's see if that even works or not. |
132 |
|
133 |
Thanks Alan. |
134 |
|
135 |
Dale |
136 |
|
137 |
:-) :-) |