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

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

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

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

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

Maciej

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