#326: Create user-facing documentation for depcheck ---------------------------+------------------------------------------------ Reporter: tflink | Owner: tflink Type: task | Status: assigned Priority: major | Milestone: 0.5.0 Component: documentation | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by jlaska):
Replying to [comment:3 tflink]:
In the section ''Fixing Failures'', it mentions adding or removing
dependencies. Would it make sense to include an example of each of those scenarios in the ''Understanding failures''?
I think that the errors are going to look the same either way since the
only thing we really detect is missing dependencies. Or are you suggesting that the fixes go into more detail and show fixing a failed depcheck run in both ways?
Yeah, a bit more detail might help, but this might be for my education. I'm hoping the recommendations we offer are actionable for maintainers. Perhaps they point to existing documents on packaging, or an SOP on resolving issues </overkill>. Of course, I don't think we need to detail *every* possible combination, but maybe thinking about specific failures, and more clearly articulating what the maintainers did to resolve the issue would help?
This got me wondering if it would help to outline several more (unique) examples of depcheck test failures in the section ''Understanding failures''. Then, for each failure listed, include a brief statement on the actual corrective action taken. In the example given already, the corrective action was to include the ''sigar.i686'' package in the x86_64 f14 repo?
Then, the section ''Fixing failures'' continues as is, with just recaping and summarizing recommended corrective action.
I'll be happy to do some mock-ups/drafts if you can point me towards unique depcheck failure logs.