flex is not a common package to use, although there are a few of the packages using it. As sometimes we need to know what does use flex (for version bumps, or to audit possible mistakes in its use, like clashing symbols), it would be quite better if instead of having it in system, the packages using it would depend on it properly.
http://tinderbox.dev.gentoo.org/misc/dindex/sys-devel/flex reports the packages depending on flex at build-time, here are more than that using it though as I recall when last flex vulnerability was found.
Out of a quick check, php is missing there.
As a side note, http://tinderbox.dev.gentoo.org/misc/rindex/sys-devel/flex lists packages depending on flex at runtime, which is probably a mistake as flex is used only at build time in 99% of its use cases.
If we can all check our build logs to see what at least _checked_ for flex and then look up if it's not in the list of packages already, we should be able to get this done quickly.
Once this is done, it's probably best to simply update the profiles.
All blocker bugs are now fixed. Can we proceed?
let's bug Jorge about the autotools change:
we can throw flex/bison into the mix at the same time ! :)
I'll try to build new stages with this in the next few days.
Just to confirm, the idea is to remove from the system set the following packages, correct?
Are there any other packages that we should drop as well?
those as well as sys-devel/m4
I'm going to use the following to build the stages:
RCS file: /var/cvsroot/gentoo-x86/profiles/base/packages,v
retrieving revision 1.50
diff -u -b -B -r1.50 packages
--- base/packages 28 May 2011 19:00:21 -0000 1.50
+++ base/packages 14 Jul 2011 01:26:09 -0000
@@ -54,15 +54,15 @@
Created attachment 280097 [details]
packages cleaned at end of stage3
I just completed a mips64 stage 1, 2, 3 with these packages removed from packages.build. Attached is the output at the end of stage3 showing which packages were removed.
Looks like it worked, and the stage builds were successful.
I feel a bit funny about removing automake/autoconf/libtool since undoubtedly, these will have to be remerged to install almost anything.
I successfully built amd64 and x86 stages with the proposed change. Thus, I've just committed the change to the tree.
I believe we can now close this bug as fixed.
*** Bug 376363 has been marked as a duplicate of this bug. ***