Richard Fish schreef:
>> Holly Bostick wrote:
>>
>>
>>So my questions are:
>>
>>1) Am I supposed to have 4 versions of binutils in the first place?
>>
>>
>>
>>
> Do you have USE 'multislot' or 'multitarget' for binutils? If so, then
> looking at /usr/portage/eclass/toolchain-binutils.eclass it seems that
> binutils becomes a slotted package, so you can have multiple versions
> installed. Otherwise, no.
Matthew Cline schreef:
>> Holly Bostick wrote:
>>
>>2) How do I get this GLSA to actually apply, or know that it's applied,
>>or whatever?
>
>
> IIRC, glsa-check has an 'inject' option for just this purpose. If you
> run glsa-check without command-line parameters, it should print out a
> usage message.
>
OK, I'm following both of you so far. Yes, I do have 'multislot' for
binutils. I admit it was just guesswork on my part; I read the USE flag
description, thought about automake and autoconf, thought that binutils
sounded like the kind of system utility that might need similar
functionality (though for reasons I wouldn't know about, as a
non-programmer), so enabled it. But of course, now I still don't know if
I actually need it or it's just causing me grief. Was it a bad call?
As far as the --inject option, yes it's there, I just didn't notice it;
Syntax: glsa-check <option> [glsa-list]
-l --list : list all unapplied GLSA
-d --dump : show all information about the given GLSA
--print
-t --test : test if this system is affected by the given GLSA
-p --pretend : show the necessary commands to apply this GLSA
-f --fix : try to auto-apply this GLSA (experimental)
-i --inject : inject the given GLSA into the checkfile
But what all this advice adds up to is that to fix this problem, I can
either:
1) trim out a bunch of binutils slots that I may or may not need (and
therefore whose loss may break unknown applications), so that glsa-check
(which is apparently broken with respect to binutils compiled with the
multislot USE flag) can accurately determine that it has applied the fix
to the binutils it perceives;
or
2) lie to glsa-check and tell it that I've fixed the problem, even
though I may still be vulnerable to it (because one of the other
versions that it has some vague sense are installed but cannot see well
enough to fix may in fact need to be fixed).
I recognize that this is really a problem with glsa-check, which is, by
it's own admission, untested/buggy, but I am, perhaps understandably,
not completly comfortable with either of these proposed solutions.
Although I'm fairly sure one or both of them would solve the presenting
symptoms, what I ultimately want is not only for glsa-check to stop
acting up, but some assurance that the GLSA is actually applied to the
application or applications in question. Frankly, glsa-check can say
whatever it wants, if I know the GLSA fixes are actually applied properly.
Can either of you, or anyone, instruct me further in these matters?
Holly
--
gentoo-user@gentoo.org mailing list
