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

[John Ellson]

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.

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

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

It wouldn't be so bad if this was the only problem.


> Maciej
>
> [1] http://wiki.opencsw.org/packaging-shared-libraries
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: graphviz-build.log
URL: <http://lists.opencsw.org/pipermail/devel/attachments/20110530/afac55fa/attachment-0001.log>