2011/5/30 John Ellson <[email protected]>: >> 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 _______________________________________________ devel mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/devel
