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.

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.

This there in F19.

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?

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.

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?

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?)

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.

(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.

(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?

(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.

(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.

(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