Bug 340771
| Summary: | multiarch conflicts in cal3d | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bill Nottingham <notting> |
| Component: | cal3d | Assignee: | Christopher Stone <chris.stone> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-11-04 23:29:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bill Nottingham
2007-10-19 21:32:51 UTC
I believe this is a bogus bug and something is either wrong with your script or there is some other multiarch problem. These are all files in %doc, and there is nothing in the MultilibTricks page about %doc files. In addition, installing both i386 and x86_64 on F7 does not produce these results. Therefore I think something else is bugged. QED. Actually I can reproduce this on F7. The %doc file is in the -devel subpackage, not the main package. When trying to install both arches in the devel subpackage the error is triggered. I don't know how to fix this other than removing all %doc files from devel which doesn't sound right. okay as Eric Sandeen pointed out, this is a problem with the "generated at ... by ..." lines in the autogenerated doc files. I'll look into fixing this. Unfortunately there are also uuid-like anchors in the html, not just the timestamps. So bigger problems. I don't know how doxygen generates these; maybe some seed based on.... I have no idea. :) I have a patch to fix the timestamps, that is easy. As for the anchors, I have no clue about doxygen. I will try to find out more. Can't we just say this a bug in yum? These packages install easily enough using rpm. If this is something built into doxygen we will have to end up putting in hacks(patches) in doxygen to get around assumptions yum makes by checking CRCs. I don't really want to jump through hoops here in my packages for what seems to me like bad logic in yum. yum and rpm behave the same - the conflicts will only show up when the i386 and x86_64 packages are installed in separate transactions (this is a rpm bug - bug 190209) Then this is clearly a bug in doxygen. doxygen would need to be patched such that it doesn't use those uuid like anchors. Asking me to pre-generate the documentation by hand every single release to work-around a doxygen limitation seems a bit messianic. Let me know if you concur, and I will create a bug so that we can enhance doxygen to work better across multi-arch installations. Sounds reasonable. This bug is not reproducible using doxygen-1.5.3 You can probably assume doxygen-1.5.3 will fix a lot of these problems. Closing as WONTFIX, this is obviously Than's responsibility to push doxygen-1.5.3. |