1 |
A few extra inline comments to reinforce what you just said: |
2 |
|
3 |
|
4 |
On Sun, 19 Aug 2012 01:02:24 +0200 |
5 |
Volker Armin Hemmann <volkerarmin@××××××××××.com> wrote: |
6 |
|
7 |
> Am Sonntag, 19. August 2012, 00:37:36 schrieb Reinhard Kotucha: |
8 |
> > Hi, |
9 |
> > I'm using Gentoo for a couple of years and am quite amazed how good |
10 |
> > it works. So thanks to all involved in its develpoment. |
11 |
> > |
12 |
> > However, after today's update, when I run revdep-rebuild, I get the |
13 |
> > message |
14 |
> > |
15 |
> > * Checking dynamic linking consistency |
16 |
> > * broken /usr/lib64/libogrove.la (requires -lstdc++) |
17 |
> > * broken /usr/lib64/libospgrove.la (requires -lstdc++) |
18 |
> > * broken /usr/lib64/libostyle.la (requires -lstdc++) |
19 |
> |
20 |
> so, find out which package these three belong to - and remove them. |
21 |
> n |
22 |
> > |
23 |
> > emerge --update --pretend |
24 |
> |
25 |
> why pretend? |
26 |
> |
27 |
> > |
28 |
> > I'm warned in advance if a portage update is available. It seems |
29 |
> > that emerge is able to warn about critical updates. |
30 |
> |
31 |
> only about portage updates. |
32 |
|
33 |
and it's hard-coded: |
34 |
|
35 |
if (update available) |
36 |
print alarming message |
37 |
|
38 |
> |
39 |
> > |
40 |
> > On the other hand it happpened several times that *after* an update |
41 |
> > I've been told that my system is completely broken and will not |
42 |
> > re-boot unless I compile a new kernel. |
43 |
> |
44 |
> really? never saw that. Only with xorg-drivers after a xorg-server |
45 |
> update. |
46 |
> |
47 |
> > It would be nice if I can be |
48 |
> > warned *before* I run emerge without the --pretend option. Then I |
49 |
> > could postpone the update to the next weekend, when I have more |
50 |
> > time. |
51 |
> |
52 |
> so you want portage to read every single ebuild, making the operation |
53 |
> A LOT longer? I am sorry but I am not willing to waste so much time. |
54 |
|
55 |
Not only that but it's impossible for portage to know this before hand |
56 |
unless some dev puts the information in the ebuild. And the infra to |
57 |
check that does not exist. |
58 |
|
59 |
This is all right correct and proper. The only way to know an update |
60 |
breaks something is to build and test it. That's how Ubuntu does it: |
61 |
the dev builds it, installs it, finds it breaks stuff. So it gets |
62 |
committed to a repo with a warning that *the*dev*already*knows*about* |
63 |
|
64 |
The Gentoo dev DOES NOT know about it, and cannot either. These |
65 |
breakages are usually dependant on the environment they are used in and |
66 |
only the user knows that. As you and I well know, the compiling Gentoo |
67 |
user is that analogy of the Ubuntu DEV |
68 |
|
69 |
> |
70 |
> > |
71 |
> > My propsal is to add a warning similar to that I get when portage |
72 |
> > updates are available, so that users know in advance that a |
73 |
> > particular update will break the system. |
74 |
> |
75 |
> please enlighten me which update breaks a system. Can't remember one. |
76 |
> Hm, back with libss&co maybe? |
77 |
|
78 |
jpeg-7, expat2 .... |
79 |
|
80 |
Those were dealt with in the only sane manner possible: |
81 |
|
82 |
~arch: tough. Keep both pieces. |
83 |
arch: news item in advance |
84 |
|
85 |
> |
86 |
> > |
87 |
> > Of course, this mailing list is not the proper place for such |
88 |
> > suggestions. Can anybody tell me whom I should ask? |
89 |
> |
90 |
> bugzilla. Feature request. |
91 |
> |
92 |
|
93 |
|
94 |
|
95 |
-- |
96 |
Alan McKinnon |
97 |
alan.mckinnon@×××××.com |