This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 469776 - pulseaudio-libs-devel.i386 conflicts with pusleaudio-libs-devel.x86_64
pulseaudio-libs-devel.i386 conflicts with pusleaudio-libs-devel.x86_64
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
: 504865 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-03 19:24 EST by Jim Radford
Modified: 2009-09-15 13:24 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-15 13:24:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A fix. (1.48 KB, text/plain)
2009-08-06 01:57 EDT, Lubomir Rintel
no flags Details

  None (edit)
Description Jim Radford 2008-11-03 19:24:08 EST
file /usr/share/doc/pulseaudio-libs-devel-0.9.13/html/annotated.html conflicts between attempted installs of pulseaudio-libs-devel-0.9.13-6.fc10.i386 and pulseaudio-libs-devel-0.9.13-6.fc10.x86_64

 [...many more message cut...]

This didn't use to be the case:

  $ rpm -q pulseaudio-libs-devel
  pulseaudio-libs-devel-0.9.13-4.fc10.i386
  pulseaudio-libs-devel-0.9.13-4.fc10.x86_64
Comment 1 Bug Zapper 2008-11-25 23:43:15 EST
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
Comment 2 Lennart Poettering 2008-12-08 13:40:06 EST
I am not sure I see what the point of fixing this might be?
Comment 3 Jim Radford 2008-12-08 14:04:40 EST
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.
Comment 4 Lennart Poettering 2008-12-18 10:02:47 EST
The thing is that I don't really know how to fix this best.

multiarch is a trainwreck.
Comment 5 Philippe Troin 2009-01-04 21:46:22 EST
> 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...
Comment 6 Lennart Poettering 2009-01-05 15:08:43 EST
(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.
Comment 7 Philippe Troin 2009-01-07 13:29:15 EST
> > 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.
Comment 8 Lennart Poettering 2009-06-10 12:17:27 EDT
*** Bug 504865 has been marked as a duplicate of this bug. ***
Comment 9 Philippe Troin 2009-06-28 03:54:21 EDT
Still broken in F11 with pulseaudio-libs-devel-0.9.15-14.fc11.
Would you accept a patch?
Comment 10 Lennart Poettering 2009-06-29 14:44:36 EDT
(In reply to comment #9)

> Would you accept a patch?  

Sure.
Comment 11 Lubomir Rintel 2009-08-06 01:57:07 EDT
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).
Comment 12 Lennart Poettering 2009-08-07 18:17:16 EDT
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.
Comment 13 Lubomir Rintel 2009-08-08 07:18:20 EDT
(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.
Comment 14 Lubomir Rintel 2009-09-15 13:24:13 EDT
bug #516339 has been fixed, which should resolve this as well. Closing this, please reopen if it did not solve the problem.

Note You need to log in before you can comment on or make changes to this bug.