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

[Maciej Bliziński]

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