[csw-devel] SF.net SVN: gar:[14667] csw/mgar/pkg/graphviz/trunk/Makefile

[John Ellson]

Maciej,

Yes please to access to a test system.  That would help a lot.   I have
access to lots of Fedora boxes locally, but only one Solaris box with
opencsw, and it only has graphviz-2.26.3 release on it.

I've attached the ldd output from the old release, if that's helpful?  
I should be very similar to the new release.
In the attachment are the outputs from:
      echo $LD_LIBRARY_PATH
      ldd  /opt/csw/bin/dot
      ldd  /opt/csw/lib/graphviz/libgvplugin_gd.so.6.0.0   


John

On 05/30/2011 07:09 PM, Maciej Bliziński wrote:
> 2011/5/30 John Ellson <ellson at opencsw.org>:
>> On 05/30/2011 04:32 PM, Maciej Bliziński wrote:
>>> 2011/5/30 John Ellson <ellson at opencsw.org>:
>>>>> If you have any questions, please ask!
>>>>>
>>>>> Thanks,
>>>>> Maciej
>>>> Yes,  basically this is getting to be too much work.   There isn't that much change in graphviz that it should be this hard.
>>> First, thank you for your effort in maintaining the graphviz package.
>>> Everybody appreciates that.  It sometimes happens that a maintainer
>>> gets overwhelmed by problems they face.  We find that teamwork is a
>>> great in these cases, where each person can solve parts of the
>>> problem.  We'll look at graphviz together.
>> Thanks.  Sorry for being cranky.
>>> As far as changes go, it's more about changes in our policy and the
>>> introduction of new checks that's at play, rather than changes in
>>> graphviz.  At times, issues with packages go unnoticed, until they are
>>> examined by checkpkg.  We've so far corrected many issues with both
>>> missing and surplus dependencies, even though packages looked okay
>>> before. There is also a possibility of getting false positives, in
>>> which case overrides can be put in place.
>>>
>>>> Why do I have to spend an hour building this (admittedly large) package, without errors, only to get all these errors when trying to post it?
>>>>
>>>> Isn't there some preliminary checking that could be done during the build on the first platform?
>>> Yes, there is a preliminary check, you should see the outcome after
>>> running "mgar package" or "mgar platforms".  There can be scenarios in
>>> which you only see an error when uploading to unstable, but these
>>> would be related to things like differences between the 5.9 and 5.10
>>> catalogs, which are rare.
>>>
>>> If your package were not checked right after building, then it's a bug
>>> and it should be investigated.  Could you run something like (if you
>>> don't use mgar, then substitute 'gmake' for it):
>>>
>>> mgar repackage 2>&1 | tee ~/graphviz-build.log
>> I did:
>>    ssh current9s
>>    cd /home/ellson/mgar/pkg/graphviz/trunk
>>    gmake repackage 2>&1 | tee ~/graphviz-build.log
>>
>> See attached.    I don't see anything like the same packaging errors in it.
> Reading through the build... I found out, why checkpkg wasn't run:
>
> # disable dependency checks because plugins depend on libs from base package
> ENABLE_CHECK = 0
>
> The checks were simply disabled in the build.
>
> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/graphviz/trunk/Makefile?view=markup&pathrev=14667
>
> Lines 14 and 15.
>
>>>> Aren't most of the dependencies automatically derivable?
>>> They are verifiable, but we do not have a code that would
>>> automatically wire package dependencies.
>>>
>>>> I don't understand the dynamic library problems ...   I'm used to having libtool take care of it all.   Whats this Rpath stuff?  Doesn't OpenCSW automatically have /opt/csw/lib in its library path?  (I mean, I know what Rpath is, but I don't know why its needed if libraries are stored in standard lib directories.  Fedora doesn't use Rpath at all.  Whats the difference?)
>>> It's one of the differences between Solaris and Linux.  On Linux,
>>> there is ld.so.conf.  It allows you to specify directories in which to
>>> look for shared libraries.  On Solaris, ld.so.conf is unavailable, so
>>> each binary needs to have that list of directories.
>> OK, but graphviz-2.26.3 doesn't have any problems with its plugins.
>>
>> e.g.:
>>
>>    echo "digraph {hello -> world}" | dot -v -Tgif >hello.gif
>>
>> uses the gd plugin from graphviz-gd.
>>
>> The plugins do use dlopen, but the plugin libs depend on other libs.
>>    ldd /opt/csw/lib/graphviz/libgvplugin_gd.so.6.0.0
>> show that the plugins find all their dependencies OK (no LD_LIBRARY_PATH
>> set).
> Could you include the full output from ldd? Please make sure you run
> ldd on a test machine (if you have one) while your updated graphviz
> packages are installed.  If you don't have a test system of your own,
> we can get you access to test9s.
>
>>>> I'm sure Imagemagick just needs a rebuild.    I'd do that except, no way, not with this kind of hassle during the packaging process.
>>> It would be hard to do without having a window of time when imagemagic
>>> is broken.  We would probably want to avoid that.  There is a couple
>>> of ways around it, such as installing updated graphviz libraries
>>> before they're released, and then releasing updated graphviz and
>>> imagemagic at the same time.  It's not the cleanest way to do this
>>> though.
>> This seems to be a more general issue.  It should be possible to rebuild
>> a set of packages and release them all at once.
> Yes, it's a general issue.  It believe that it has been discussed at
> length on the mailing list in the past.  There is a couple rules at
> play here:
>
> - packages need to be built on the buildfarm
> - you need to release a package before it can be installed on the buildfarm
> - you need to install a package on the buildfarm before you can
> rebuild another package against it
> - all the required shared libraries must be present in the catalog at all times
>
> You need to plan the rebuild so that these rules are preserved.
>
>>>> Personally I'd like to avoid multiple library versions installed in parallel.  It can be a support nightmare.
>>> We've got that figured out, you can look up the wiki page about shared
>>> libraries if you're curious how.
>> Mmm, with 5 differnt orthogonal numbering schemes.  Complexity on
>> complexity.
>>
>> OK, I'm still feeling cranky.
> Yes, you seem to be.  Thats OK, I imagine that it's not a pleasant
> experience to suddenly see that many reported errors against your
> package.  I'm currently rebuilding graphviz on the buildfarm to
> examine the situation more closely.  I'll wait for the ldd output on
> your test system.
>
> Thanks,
> Maciej
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: some_ldd_results_for_graphviz_2.26.3.txt
URL: <http://lists.opencsw.org/pipermail/devel/attachments/20110530/c401941c/attachment.txt>