| Summary: | allow package manager to wrangle known failures | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nick Fortino <nfortino> |
| Component: | [OLD] Core system | Assignee: | Package Manager Specification <pms> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | enhancement | CC: | spatz |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Nick Fortino
2009-03-27 21:30:25 UTC
*** 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. |
