On Sat, Oct 18, 2014 at 08:35:29PM -0300, Gez wrote:
El sáb, 18-10-2014 a las 12:15 -0700, Josh Andler escribió:
On Sat, Oct 18, 2014 at 6:22 AM, Gez <listas@...3059...> wrote:
As the user who reported the bug being discussed, I'd like to add that for my workflow (and I'm sure that many people's workflows too) including bitmap images in vector illustrations is a critical feature. Removing the ability to work with bitmaps is a no-go. If I install Inkscape from the repositories and find that I would immediatelly roll back to the previous version. People getting a program from repository expects that the program works. Period.
Anyone who would be getting it from a repository (minus the Stable PPA unless we provide cairo there too) WILL HAVE the correct version of cairo. It has been released. When it comes to spring distro releases, it will not be an issue. It will really only potentially be an issue for LTS users who want to compile Inkscape themselves. You keep saying from repos, so I need to emphasize, it won't be an issue for people getting it from vendor repos.
You say it's not an issue because at the time of the release of Inkscape all the distros that could offer inkscape 0.91 will already have the right version of Cairo, right?
In practice, yes.
That's true, and I know this is rather unlikely, but if some distro decides to stick to the previous version of Cairo for whatever reason and a packager builds inkscape for their repos, the issue would affect all of their users.
It's unlikely but not impossible.
Correct, it's not impossible. It's a legitimate concern.
LTS users who want to compile themselves, on the other hand, are better equiped to deal with a dependency not met. As I mentioned earlier, you can install the right cairo version in a different prefix and load it when the inkscape binary is executed (that's how I tried it without messing with my system-wide cairo).
If it were any of our other dependency libraries I'd tend to agree.
Cairo is used by a lot of different applications, from evince to web browsers to administration tools... In theory, you could leave your old version of libcairo2 in /usr/lib, and install the new 1.14 to /usr/local/lib, and all would be good. That's how it's *supposed* to work. Then you build inkscape against the /usr/local/lib version of the library and get the best of both worlds.
In my experience though (and I reinstall cairo A Lot), odd problems can crop up when you do this. For example, I'd omitted PDF support for my /usr/local/lib/ installed libcairo2, and suddenly evince broke and web browser printing quit working properly.
I fear that making inkscape installation *harder* in order to save inexperienced users from seeing this bug, we may inadvertantly lead them into a situation where they're inadvertently break their system.
My point is that people who chose an LTS distro but want to run a new version of the program that they can only get by compiling the sources, are probably prepared to deal with it, and building the new cairo will be at their reach. Using Inkscape with the old cairo brings back a very nasty bug that breaks lots of people's workflows. Making the new version of a dependency avoids that and only creates an extra problem to people who are likely to be able to deal with it.
Hmm, I see where you're coming from (and thank you for arguing the point) but I come to the opposite conclusion. If, as you say, building a new cairo is within their reach, and they're going to build Inkscape from scratch (rather than use a PPA), then we should be able to safely assume if/when they run into this particular bug they'd know enough to read Known Issues and Release Notes and so forth, and learn that they should upgrade their cairo as well.
My guess is that the lion's share of LTS users are going to just install from a PPA (or equivalent), and that's where we should be focusing our efforts. Such a PPA would include both Inkscape builds and new Cairo 1.14 system packages, and it'd all Just Work.
The audience we're arguing about - LTS users compiling from scratch - are probably going to be quite a small crowd. My guess here is they're not going to be a bunch of neophytes, but rather are going to be technically apt folks (since they're ok compiling from scratch) who just like keeping their system stable (since they run LTS versions). I think it's safe to assume such cautious techies will read NOTICES we post, and I also think they'll appreciate having the flexibility to choose what the priority is for them: System stability trading off rendering quality, vs. good downscaling quality trading off potential system bugs.
Trust me, I've put a good share of effort into making sure this bug is adequately solved. I certainly don't want it to see it continue to afflict people! At the same time, I know how risk-adverse LTS users are and how much risk taking we're asking of them if we demand they upgrade Cairo. My preference is to educate them about the choices and let them decide which path is right for them.
If their usage model involves embedding bitmaps in SVG documents, then it's going to be an easy choice! And we can totally support them. OTOH, if they're an occasional Inkscape user who want's the latest and greatest but isn't willing to take a risk with a system library and doesn't care about downscaling bitmaps, we can totally support them too.
Bryce