1 |
Marc Joliet <marcec@×××.de> posted |
2 |
1184510146.11699.33.camel@××××××××××××××××××××××××××××××.de, excerpted |
3 |
below, on Sun, 15 Jul 2007 16:35:46 +0200: |
4 |
|
5 |
> I only activated [collision-protect] because I also run games and I |
6 |
> recall it being recommended to activate it when using 3rd party |
7 |
> binaries. |
8 |
|
9 |
Makes a lot of sense. My /personal/ feelings on binary-only... well, |
10 |
just look at my sig. So I don't have that particular problem, but |
11 |
collision-protect makes a lot of sense if folks /do/ choose to install |
12 |
that sort of thing. |
13 |
|
14 |
>> Have you seen http://bugs.gentoo.org/show_bug.cgi?id=80846 (which is |
15 |
>> linked from the bug you mentioned)? It looks like either that bug or a |
16 |
>> special case very similar to that bug. What portage are you running? |
17 |
>> Is it the 2.1.2 series past the -pre1 mentioned in that bug? Is |
18 |
>> portage updated to the latest stable on your system? |
19 |
> |
20 |
> No, I haven't seen it. Though I can't tell if it may be related, plus |
21 |
> the bug is marked "resolved fixed", so I assume it still is. Though I am |
22 |
> confused as to how a collision in glibc could have been missed. That's |
23 |
> why I thought it may be an error on my account, or a broken file |
24 |
> somewhere (and the likes). |
25 |
|
26 |
Well, resolved-fixed means there's an ebuild with the fix available, but |
27 |
whether it has reached stable or not is an entirely different question. |
28 |
Additionally, regressions aren't entirely unheard of. Occasionally, some |
29 |
bugs reappear, for various reasons, and must be squashed once again. |
30 |
|
31 |
Of course, as I said, I'm not sure if this is exactly the same bug or |
32 |
simply related... There are also various complexities with collision- |
33 |
protect as the bug explains. I'm not entirely sure there's a proper |
34 |
solution to all of them at the same time, which then implies that "hack" |
35 |
solutions like simply exempting specific files, may be necessary. |
36 |
However, I'm far from expert enough to know if this is such a case, and |
37 |
the fact that it's occurring on a package as basic as glibc... yes, it |
38 |
needs to be filed as a bug and /something/ fixed, even if it's ultimately |
39 |
just a hack. |
40 |
|
41 |
> Also, I am very up to date. I run a cron-job every day at 23:00 to sync |
42 |
> and then manually update. So I have the most recent stable of everything |
43 |
> I have, along with a select few applications as ~amd64 and exactly 3 |
44 |
> packages unmasked (ut99 related packages). |
45 |
|
46 |
Well, there's also the whole "--deep" thing. Without --deep added to |
47 |
your updates, portage updates stuff in your world file (or specifically |
48 |
listed as system by your profile), but not necessarily "deep" |
49 |
dependencies thereof. For example, portage is part of system so it'd be |
50 |
updated in any case, but it depends on python. python would only be |
51 |
updated if you specify --deep, if portage (or some other package) |
52 |
specifies that it needs something newer than you have merged, or when the |
53 |
particular version you have merged gets masked or removed from the |
54 |
tree. /Normally/, outdated dependencies are caught and the ebuild |
55 |
updated to require newer versions if necessary, but newer versions do |
56 |
often include bug fixes for corner cases, and sometimes those corner |
57 |
cases aren't always caught. |
58 |
|
59 |
Here, I just use --deep on my emerge --update world runs as a matter of |
60 |
course, so I know I always have the latest unmasked versions available. |
61 |
It does avoid problems on occasion, but the tradeoff is that sometimes |
62 |
updating those deep dependencies forces a recompile of other things (what |
63 |
revdep-rebuild is designed to catch), so there's rather more compiling to |
64 |
be done than there would be if I didn't choose to use --deep. |
65 |
|
66 |
So it's up to you. More compiling with --deep, or less compiling, but |
67 |
chasing down the occasional additional bug, if you don't use --deep. |
68 |
|
69 |
Anyway, as you can see, there's more to the question of whether you are |
70 |
up to date, than the question on its surface would imply. |
71 |
|
72 |
(Oh, in case you were wondering, my meatspace friends too have learned to |
73 |
ask someone else if they want a simple answer. If they ask me, 10 |
74 |
minutes after they've generally lost interest because all they wanted was |
75 |
a simple 2 second general case yes/no, I'm still explaining all the |
76 |
special-case caveats and exceptions to the general rule, when they occur |
77 |
and why, and what can be done to avoid the corner case or ameliorate the |
78 |
situation when it does occur. =8^\ At least on newsgroups and lists, |
79 |
there's opportunity for a variety of responses, so folks can pick the one |
80 |
they want, detailed or not. Mine are generally the latter. =8^] ) |
81 |
|
82 |
-- |
83 |
Duncan - List replies preferred. No HTML msgs. |
84 |
"Every nonfree program has a lord, a master -- |
85 |
and if you use the program, he is your master." Richard Stallman |
86 |
|
87 |
-- |
88 |
gentoo-amd64@g.o mailing list |