Every so often, an error or misconfiguration in core package manages compile, only to break its dependencies. There is little recourse to force the user to upgrade a broken package he doesn't know about, especially if package.mask or rev-bump options are undesirable (say the error is thought to affect only 5% of users). This results in a mass of duplicates being filed without good reason. Recent examples are bug 236558 and bug 262567. Experienced devs and the duplicates page could probably come up with more. I propose a known_issues file in profiles/ which will help the user solve the issues at hand. As a first shot, here is the proposed format, similar to package.mask: #Dev Name (date) #Short comment string or regexp to be found in build.log error message to be output to user if found The two bugs above would have something like: # Dev E. Loper <developer@gentoo.org> (15 Mar 2009) # Bad gcc patch, 60 day expected impact 'libfaad2/cfft.c:1001: internal compiler error:' "You are suspected to have hit bug 262567. Please remerge gcc and try again" # Dev E. Loper <developer@gentoo.org> (03 Sep 2008) # bad pixman use flag combination. # Should be removed 60 days after ebuild is patched 'undefined reference to `pixman_have_sse' "pixman seems to be mis-configured. Check that pixman does not have the use flag combination USE: -mmx sse2. See bug 236558 for details"
*** This bug has been marked as a duplicate of bug 208759 ***
Sorry, wrong bug.
I think this is basically the same thing that GLEP 42 is meant to address: http://www.gentoo.org/proj/en/glep/glep-0042.html
I disagree that GLEP 42 addresses this issue. My understanding is that GLEP 42 is an attempt to keep users informed of intentional changes in the tree, and to preempt any known issues a specific install may cause. This proposal attempts to address the situation when the following 5 conditions are met: 1. The system has been broken by an unknown error upstream, an unknown error by a dev, or by a supported use flag combination which happened to be invalid. 2. The failure is silent; that is, at the time the true illegal operation occurred, there is no reason to suspect anything went wrong. Indeed, at the time of failure, it may be that nobody knew such a failure could occur. 3. The impact of the failure is not expected to be widespread enough to warrant tricks such as masking the offending package, rev-bumping, etc. which would force all users of tree to upgrade a package. 4. The symptoms of the failure (later on) are easily detectable by a simple grep in the build.log. 5. (optional) The symptoms of the failure are not easily traced back to the offending package. Thus, (unless one happens to know the correct keywords from the build log), there is little chance a user giving a half hearted try to avoid submitting a duplicate bug will ever find what they are looking for. I fail to see how GLEP 42 could be leveraged to address this issue, in light of point 3, as there may be no way to detect a past failure until it's symptoms arise. Simply releasing a news item on the failure would violate the relevancy requirement of GLEP 42. While I disagree, leaving as RESOLVED in case I missed something obvious.
(In reply to comment #4) > 4. The symptoms of the failure (later on) are easily detectable by a simple > grep in the build.log. > 5. (optional) The symptoms of the failure are not easily traced back to the > offending package. Thus, (unless one happens to know the correct keywords from > the build log), there is little chance a user giving a half hearted try to > avoid submitting a duplicate bug will ever find what they are looking for. > > I fail to see how GLEP 42 could be leveraged to address this issue, in light of > point 3, as there may be no way to detect a past failure until it's symptoms > arise. Simply releasing a news item on the failure would violate the relevancy > requirement of GLEP 42. I suppose we could extend GLEP 42 to support a new header which can be used to specify a pattern for searching the build log. I think that would make more sense than creating an entirely separate news system.
Can't we just get people to write better die messages?
What would you write if there are several reasons for make to fail, list all open bugs and solutions? They idea is to show the user relevant information about the problem he's having, not flooding him with irrelevant stuff for him to sort out.
No progress since more than 10 years, therefore closing. Feel free to reopen with a concrete proposal.
