What does garnome vs. jhbuild got to do with anything? The bug report clearly says "pango 1.9.1", which is their development series. "Cairo 0.9.0" is also a development release. Both now have stable releases (1.10.0, and 1.0.0, respectively). Development releases aren't usually supported by their own maintainers, even if they come in tarball form. I certainly am not going to support people using my library against unstable versions of other people's libraries. Further, if you look at the bug report, you'll see that it's not my job to track my dependency's dependencies. That's upstream of me, and should be handled by pkg-config.
What's rude is assuming that librsvg tracks or would want to track CVS HEAD GNOME dependencies, which it doesn't. What's rude is assuming that its development and release schedule is tied to GNOME's, which it isn't. We do things on our own timeline, and I'll release a tarball when I think that the thing is ready to be released, and not because you say so. What's rude is then asking your users to file bugs against my product because you've gone and done something stupid. I won't be a support line for your "highly unofficial" mistakes. What's confusing is that you used the librsvg HEAD branch instead of the GNOME-2-12 branch to create this "highly unofficial" tarball. Why haven't you submitted your 'make dist' patch upstream? Or your version patch?
You made several assumptions about librsvg and my intentions without consulting me or Caleb. You then acted upon those wrong assumptions (granted, with the admirable intention of wanting to help out your users) in a way that affected your users. Now you contend that your missteps and wrongheaded assumptions should somehow reflect poorly on me instead of you. That's absurd - pull your head out and get a clue. How you handle your users is your problem, not mine.
WRT bug 314400, librsvg has never had a promise of API/ABI stability. In light of that, I've marked those few functions as deprecated for the better part of 2 years. I've informed Sven and others that they're deprecated. So now in a *unreleased development version* of librsvg, I've removed the deprecated functions. As librsvg is in the midst of a major overhaul in terms of its API and what it's implemented in terms of (Cairo vs Libart), I don't think that's a problem. The HEAD version wasn't meant to be used against the GNOME 2.x series anyway. Use the GNOME-2-12 branch if you want the API/ABI stability, which I've left in to make folks like Sven happy. As far as I'm concerned, bug 314400 is a bug in the Gimp or your faulty assumptions. For now, I've reassigned it to the Gimp.
Anyhow, don't you think that it's hypocritical to file bug 313349 against librsvg because I allegedly haven't tracked new and unstable pango/cairo/gtk+ API/ABI changes, and then file bug 314400 against librsvg because I've broken API/ABI in an unreleased unstable version? By your reasoning, why shouldn't the Gimp be forced to track my unstable, fluctating API/ABI? So it's my fault both times. I contend that this is inconsistent reasoning. When you mix and match development versions of things - especially unreleased development versions of things-, caveat emptor.
Finally, WTF's up with your ChangeLog complaints? You're meandering and really ranting here. In an ideal world, I'd paste in the whole bug conversation and sample files, but I think that'd be a bit absurd. Learn how to use bugzilla. You can figure out what's been fixed in a certain module since a certain day. Don't be lazy and complain that you don't know "what's been fixed" when the ChangeLog and bugzilla both will tell you so readily. Don't cop-out and blame me for your own laziness, ineptitude, or both.
You could've avoided all of this if you'd just taken 2 seconds out of your day to join #librsvg and talk with me and Caleb. Pull your finger out and join the channel or write an email. But instead you decided to assume things and then act like a jerk because your assumptions didn't pan out like you'd hoped they would.