[gentoo-amd64] Re: [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64

[Duncan <1i5t5.duncan@cox.net>]

Marc Joliet <marcec@gmx.de> posted
1184510146.11699.33.camel@marcec.huntemann.uni-oldenburg.de, excerpted
below, on  Sun, 15 Jul 2007 16:35:46 +0200:

> I only activated [collision-protect] because I also run games and I
> recall it being recommended to activate it when using 3rd party
> binaries.

Makes a lot of sense.  My /personal/ feelings on binary-only... well, 
just look at my sig.  So I don't have that particular problem, but 
collision-protect makes a lot of sense if folks /do/ choose to install 
that sort of thing. 
 
>> Have you seen http://bugs.gentoo.org/show_bug.cgi?id=80846 (which is
>> linked from the bug you mentioned)?  It looks like either that bug or a
>> special case very similar to that bug.  What portage are you running? 
>> Is it the 2.1.2 series past the -pre1 mentioned in that bug?  Is
>> portage updated to the latest stable on your system?
> 
> No, I haven't seen it. Though I can't tell if it may be related, plus
> the bug is marked "resolved fixed", so I assume it still is. Though I am
> confused as to how a collision in glibc could have been missed. That's
> why I thought it may be an error on my account, or a broken file
> somewhere (and the likes).

Well, resolved-fixed means there's an ebuild with the fix available, but 
whether it has reached stable or not is an entirely different question.  
Additionally, regressions aren't entirely unheard of.  Occasionally, some 
bugs reappear, for various reasons, and must be squashed once again.

Of course, as I said, I'm not sure if this is exactly the same bug or 
simply related...  There are also various complexities with collision-
protect as the bug explains.  I'm not entirely sure there's a proper 
solution to all of them at the same time, which then implies that "hack" 
solutions like simply exempting specific files, may be necessary.  
However, I'm far from expert enough to know if this is such a case, and 
the fact that it's occurring on a package as basic as glibc... yes, it 
needs to be filed as a bug and /something/ fixed, even if it's ultimately 
just a hack.

> Also, I am very up to date. I run a cron-job every day at 23:00 to sync
> and then manually update. So I have the most recent stable of everything
> I have, along with a select few applications as ~amd64 and exactly 3
> packages unmasked (ut99 related packages).

Well, there's also the whole "--deep" thing.  Without --deep added to 
your updates, portage updates stuff in your world file (or specifically 
listed as system by your profile), but not necessarily "deep" 
dependencies thereof.  For example, portage is part of system so it'd be 
updated in any case, but it depends on python.  python would only be 
updated if you specify --deep, if portage (or some other package) 
specifies that it needs something newer than you have merged, or when the 
particular version you have merged gets masked or removed from the 
tree.  /Normally/, outdated dependencies are caught and the ebuild 
updated to require newer versions if necessary, but newer versions do 
often include bug fixes for corner cases, and sometimes those corner 
cases aren't always caught.

Here, I just use --deep on my emerge --update world runs as a matter of 
course, so I know I always have the latest unmasked versions available.  
It does avoid problems on occasion, but the tradeoff is that sometimes 
updating those deep dependencies forces a recompile of other things (what 
revdep-rebuild is designed to catch), so there's rather more compiling to 
be done than there would be if I didn't choose to use --deep.

So it's up to you.  More compiling with --deep, or less compiling, but 
chasing down the occasional additional bug, if you don't use --deep.

Anyway, as you can see, there's more to the question of whether you are 
up to date, than the question on its surface would imply.

(Oh, in case you were wondering, my meatspace friends too have learned to 
ask someone else if they want a simple answer.  If they ask me, 10 
minutes after they've generally lost interest because all they wanted was 
a simple 2 second general case yes/no, I'm still explaining all the 
special-case caveats and exceptions to the general rule, when they occur 
and why, and what can be done to avoid the corner case or ameliorate the 
situation when it does occur.  =8^\  At least on newsgroups and lists, 
there's opportunity for a variety of responses, so folks can pick the one 
they want, detailed or not.  Mine are generally the latter. =8^] )

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list