Bug 469776
| Summary: | pulseaudio-libs-devel.i386 conflicts with pusleaudio-libs-devel.x86_64 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jim Radford <radford> | ||||
| Component: | pulseaudio | Assignee: | Lennart Poettering <lpoetter> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 10 | CC: | andreas.bierfert, kdekorte, lkundrak, lpoetter, phil | ||||
| 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: | 2009-09-15 17:24:13 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: | |||||||
| Attachments: |
|
||||||
|
Description
Jim Radford
2008-11-04 00:24:08 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I am not sure I see what the point of fixing this might be? I have a need to build both x86_64 and i386 releases and to generally keep things building in both environments, so I install both versions of lots of devel packages. Having conflicts just creates install hassles for no good reason. The thing is that I don't really know how to fix this best. multiarch is a trainwreck. > The thing is that I don't really know how to fix this best. #1: Split out the docs into a separate #2: Change the build process so that the docs generation produces the same output on i386 and x86_64. > multiarch is a trainwreck. It's been working fine for 4+ years. Why is it a train-wreck? F10 dropped the option to install 32-bit packages alongside 64-bit packages, that's why there are so many multilib bugs... (In reply to comment #5) > > The thing is that I don't really know how to fix this best. > > #1: Split out the docs into a separate Hmm, so just because multilib is a trainwreck I need to split up my packages at otherwise pointless places? > #2: Change the build process so that the docs generation produces the same > output on i386 and x86_64. How would that look like? > > multiarch is a trainwreck. > > It's been working fine for 4+ years. Oh, I disagree. > Why is it a train-wreck? For one reason: see above. > > Why is it a train-wreck? > > For one reason: see above. All I see is circular logic. If you have any beef with multilib support in Fedora, please vent it somewhere else.http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks Anyways, please check: http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks and look at the "Doxygen footers" section. It should fix the problem without have to split a separate doc package. *** Bug 504865 has been marked as a duplicate of this bug. *** Still broken in F11 with pulseaudio-libs-devel-0.9.15-14.fc11. Would you accept a patch? (In reply to comment #9) > Would you accept a patch? Sure. Created attachment 356468 [details]
A fix.
I tested this to an extent to which is it possible to test a mutlilib patch on i386 (forcing in the dependencies and ignorearch-ing the foreign package).
Hmm, I'd prefer a fix that allows us to use default footer. Changing the documentaton system because multilib is a bi too limited, doesn't seem like the right approach to me. (In reply to comment #12) > Hmm, I'd prefer a fix that allows us to use default footer. Changing the > documentaton system because multilib is a bi too limited doesn't seem like the > right approach to me. Well, with the default footer (that contains a timestamp) I can't think of a solution that would be less ugly than this. I tend to think the right way would be to modify the Fedora doxygen package not to include a timestamp in default footer (there seem to be no reason for sticking timestamps across the documentation, especially if user didn't explicitly request them), but given how obvious does that seem and yet noone did that I suspect there might be some problem with that. I opened a bug #516339 against doxygen, let us see what happens. bug #516339 has been fixed, which should resolve this as well. Closing this, please reopen if it did not solve the problem. |