On 11/01/2010 08:07, Charles Wilson wrote:
Suppose ABI #3 is released

It won't be; librsvg follows the standard GNOME pattern of keeping API stability by keeping deprecated features while adding new ones. The next change would be a separate librsvg3, probably later this year when glib and gtk+ 3.0 are released.

Furthermore, neither ImageMagick nor libAfterImage care about gtk's
ability to load the svgs -- they don't need
    /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.dll
    /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.la
    /etc/postinstall/librsvg2.sh (which only has anything to do with
svg_loader).

Despite the path, it is really a plugin for GdkPixbuf and does not depend on GTK+. Hence, there are no extra dependencies for the SVG loader, since librsvg2 itself also depends on libgdk_pixbuf2.0.

OTOH I'm not opposed to separating the loader into its own package.

I think svg_loader* and the postinstall script should go into a new
package "gtk2.0-loaders-svg",

gdk-pixbuf2.0-svg would be more accurate, and this naming scheme is also used by the WMF loader provided by libwmf.

and the /usr/share/doc/librsvg2/* should go into a new package
> "librsvg2-doc" along with all of the html/* files from librsvg2-devel.

The docs in $pkgdocdir are the standard COPYING/NEWS/README docs that all users should receive, but the html docs in librsvg2-devel are gtk-doc API documentation that would only be of interest to developers and packagers.

Otherwise, rebuilds fine from source and passes its builtin testsuite.

Thanks for the review,


Yaakov

Reply via email to