Bug 831392 - graphviz multilib conflict
graphviz multilib conflict
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: graphviz (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaroslav Škarvada
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-12 18:34 EDT by Philippe Troin
Modified: 2013-11-05 10:53 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-04 10:48:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Philippe Troin 2012-06-12 18:34:28 EDT
# yum install graphviz      
Loaded plugins: changelog, downloadonly, priorities, remove-with-leaves, show-
              : leaves, tsflags
16 packages excluded due to repository priority protections
Package graphviz-2.28.0-16.fc17.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package graphviz.i686 0:2.28.0-16.fc17 will be installed
--> Processing Dependency: libgvplugin_gd.so.6 for package: graphviz-2.28.0-16.fc17.i686
--> Running transaction check
---> Package graphviz-gd.i686 0:2.28.0-16.fc17 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package             Arch         Version                  Repository      Size
================================================================================
Installing:
 graphviz            i686         2.28.0-16.fc17           fedora         1.1 M
Installing for dependencies:
 graphviz-gd         i686         2.28.0-16.fc17           fedora          27 k

Transaction Summary
================================================================================
Install  1 Package (+1 Dependent package)

Total size: 1.1 M
Installed size: 3.5 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test


Transaction Check Error:
  file /usr/bin/acyclic from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/bcomps from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/ccomps from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/cluster from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/diffimg from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/dijkstra from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/dot from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/dot_builtins from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gc from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gml2gv from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gvcolor from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gvgen from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gvmap from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gvpack from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gvpr from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/gxl2gv from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/lefty from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/mm2gv from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/nop from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/prune from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/sccmap from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/tred from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64
  file /usr/bin/unflatten from install of graphviz-2.28.0-16.fc17.i686 conflicts with file from package graphviz-2.28.0-16.fc17.x86_64

Error Summary
-------------

[2]    12050 exit 1     noglob yum install graphviz
Comment 1 Fedora End Of Life 2013-07-03 18:58:10 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 2 Fedora End Of Life 2013-07-31 21:13:53 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 3 Philippe Troin 2013-10-14 12:46:52 EDT
This there in F19.
Comment 4 John Ellson 2013-10-14 13:33:09 EDT
I don't understand why you think there wouldn't be conflicts between an i686 and an x86_64 binary installed in the same place?    Why not just install one architecture?
Comment 5 Philippe Troin 2013-10-14 13:53:29 EDT
The graphviz package contains libraries, not just executables.
I have 32-bit binary that I cannot recompile that uses the graphviz libraries.
I want to use this binary on a 64-bit system.

That's the whole point of multilib.
Graphviz is incorrectly packaged and does not allow me to do that.

See https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

It looks like the solution would be to split graphviz into graphviz-libs (libraries) and graphviz (binaries).
Graphviz-libs and libs-devel would be the only ones available as both i386 and x86_64.
Comment 6 John Ellson 2013-10-14 15:24:44 EDT
I'd like some input on this from the Fedora package maintainer, please.

Currently, the packages are designed for three use cases:  1) minimal (e.g. a webserver without X11),   2) desktop (with X11), 3) extras.    I tried to meet these cases with minimal packages.  Packaging for multilib is orthogonal to this.

Your need to build i686 binaries could be achieved by building on a i686 host, or virtual host, or by only installing i686 packages on an x86_64 host.

I understand the idea of separating the libraries, but it looks to me as though that would add at least four additional packages:  graphviz-libs, graphviz-x-libs, graphviz-libs-devel, graphviz-x-libs-devel,  and maybe more.  Perhaps each lib, and each plugin should be in its own package?


Thoughts?
Comment 7 John Ellson 2013-10-14 16:37:35 EDT
Perhaps its not as bad as I was thinking.

I made a change to my upstream packaging to provide a new graphviz-libs rpm
with just the following files (64 bit build):

/usr/lib64/libcdt.so.5
/usr/lib64/libcdt.so.5.0.0
/usr/lib64/libcgraph.so.6
/usr/lib64/libcgraph.so.6.0.0
/usr/lib64/libgvc.so.6
/usr/lib64/libgvc.so.6.0.0
/usr/lib64/libgvpr.so.2
/usr/lib64/libgvpr.so.2.0.0
/usr/lib64/libpathplan.so.4
/usr/lib64/libpathplan.so.4.0.0
/usr/lib64/libxdot.so.4
/usr/lib64/libxdot.so.4.0.0

The changes are in GitHub now:   http://github.com/ellson/graphviz/

Eventually binaries will show up in http://www.graphviz.org/, but my build farm is down at the moment so it may take a few days.

Perhaps The Fedora maintainer could look at my changes and do something similar with Fedora's graphviz.spec?

(BTW.  Could you see if you can make graphviz-docs, and graphviz-graphs into noarch rpms while you are in there?)
Comment 8 Jaroslav Škarvada 2013-11-04 10:48:33 EST
This is fixed in f20, graphviz-2.34.0-4. This was an regression due to filter_setup macro.

The only two conflicts remaining are caused by deps from graphviz-R. This is caused by bug in the R-core package, which is not multilib clean - this is out of my scope, but I can file a bug about it.

The another problem is in graphviz-php, there is a symlink installed:
/usr/share/php/gv.php -> /usr/lib(64)/graphviz/php/gv.php
which is different on 32 bits and 64 bits (on fedora), due to /usr/lib and /usr/lib64 paths.
This could be fixed by e.g. removing the symlink and adding wrapper code into /usr/share/php/gv.php that would include the right /usr/lib(64)/graphviz/php/gv.php according to current architecture. John, could you fix this upstream?

Regarding the graphviz-libs, thanks I will push it into rawhide.

I am closing this as next release, because the core packages are fixed in f20 and up. If you need to backport this fix into f19, please let me know or reopen this bug.
Comment 9 Jaroslav Škarvada 2013-11-04 12:07:51 EST
(In reply to Jaroslav Škarvada from comment #8)
> The only two conflicts remaining are caused by deps from graphviz-R. This is
> caused by bug in the R-core package, which is not multilib clean - this is
> out of my scope, but I can file a bug about it.
> 
Filled bug 1026455.
Comment 10 John Ellson 2013-11-04 13:53:17 EST
(In reply to Jaroslav Škarvada from comment #8)
> The another problem is in graphviz-php, there is a symlink installed:
> /usr/share/php/gv.php -> /usr/lib(64)/graphviz/php/gv.php
> which is different on 32 bits and 64 bits (on fedora), due to /usr/lib and
> /usr/lib64 paths.
> This could be fixed by e.g. removing the symlink and adding wrapper code
> into /usr/share/php/gv.php that would include the right
> /usr/lib(64)/graphviz/php/gv.php according to current architecture. John,
> could you fix this upstream?


The linked gv.php file is identical on all architectures, and the SWIG-generated code already takes care of dll variations, so I think all that is needed is a cp instead on ln so that there is no reference to /usr/lib(64)/ ?

https://github.com/ellson/graphviz/commit/fd5031a439615950bf17220e62f0ad4fd64e2f27

I'm hoping its OK for an identical file to be written by multiple arch packages without raising a multilib conflict?
Comment 11 Jaroslav Škarvada 2013-11-05 05:04:17 EST
(In reply to John Ellson from comment #10)
> The linked gv.php file is identical on all architectures, and the
> SWIG-generated code already takes care of dll variations, so I think all
> that is needed is a cp instead on ln so that there is no reference to
> /usr/lib(64)/ ?
> 
> https://github.com/ellson/graphviz/commit/
> fd5031a439615950bf17220e62f0ad4fd64e2f27
> 
This will work, but in Fedora we tried to avoid packaging of identical copies of the same file.

> I'm hoping its OK for an identical file to be written by multiple arch
> packages without raising a multilib conflict?
>
RPM has colouring feature. Basically for binaries, they can (and normally are) different between arches and when installing both packages (e.g. x86_64 and i686 variants) at the same time the binary with the most prio colour (in this case x86_64 variant) will win and there is no conflict. For non binaries, the content needs to be the same to be multilib clean, so the answer is yes.
Comment 12 John Ellson 2013-11-05 09:35:39 EST
(In reply to Jaroslav Škarvada from comment #11) 
> > https://github.com/ellson/graphviz/commit/
> > fd5031a439615950bf17220e62f0ad4fd64e2f27
> > 
> This will work, but in Fedora we tried to avoid packaging of identical
> copies of the same file.


I will convert the other ln's to cp's, and then the rpm spec can exclude the originals.    I was trying to solve a problem of non-priviledged "make install",
for example when a user wants to install under theur $HOME.   A situation that doesn't apply here.
Comment 13 John Ellson 2013-11-05 10:53:00 EST
(In reply to John Ellson from comment #12)
> (In reply to Jaroslav Škarvada from comment #11) 
> > > https://github.com/ellson/graphviz/commit/
> > > fd5031a439615950bf17220e62f0ad4fd64e2f27
> > > 
> > This will work, but in Fedora we tried to avoid packaging of identical
> > copies of the same file.
> 
> 
> I will convert the other ln's to cp's, and then the rpm spec can exclude the
> originals.    I was trying to solve a problem of non-priviledged "make
> install",
> for example when a user wants to install under theur $HOME.   A situation
> that doesn't apply here.

Ended up just converting ln's to mv's  -- but it looks like the last change wasn't quite right anyway.

https://github.com/ellson/graphviz/commit/f11aead0a5faf30a2a9f626826d9d5a8950e336f

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