The cairo-1.0.o ebuild fails to build the postscript and pdf backends; those backends should be installed (at least conditionally). In previous versions they defaulted to enabled, in 1.0.0 they are (evidently) defaulting to disabled. There really isn't any reason not to build and install them, but if anyone objects anyway, they can be conditional on use flags. (I'd suggest pdf and postscript as the names of the flags.) So, either '--enable-pdf --enable-ps' should be added the the econf call, or '$(use_enable pdf) $(use_enable postscript ps)' should be. If flags are used, these entries can be added to use.local.desc: x11-libs/cairo:pdf - Build with PDF support x11-libs/cairo:postscript - Build with PostScript support
Assigning to gnome, and moving me to CC, leonardop has been doing these bumps and added gnome to the herd in metadata.xml
Thanks for your interest, however, there is a reason why those backends are not enabled by default upstream, and, personally, I don't find any real need to enable them in the ebuild. Users can always test those backends, and are encouraged to do so, but relying on local USE flags is not really necessary, and probably not a good idea considering those backends will probably be enabled by default again down the line when their APIs are ready. If there is a package in the tree that really needs any of those backends, or another dev(s) has any strong reasons to enable them, feel free to take care of this bug.
Actually latexer, Gentopia has been the one working on the cairo development and sending patches upstream. The Portage tree changes done by Leo have been based off Gentopia work. Just saying this cause we're the ones familiar with the code base. I honestly do not see a reason why we don't provide the postscript and pdf as USE flags. It's not that they will rm -rf your machine it's more that their APIs are not solidified and they might not produce the same results of other backends. However it is up to the users to be given the ability to test these. Especially since cairo is still package.masked there is no reason to remove functionality that was previously there. That's just my feeling on the subject.
*** Bug 105245 has been marked as a duplicate of this bug. ***
Assigning to maintainer listed in metadata. Leo: Can we have a final decision to either add the flags in the latest version or close this bug until upstream changes their mind about the backends? Also removing blocker on gnome-2.12 stable bug since it doesn't effect gnome in any way
Joe, My opinion is that we should keep those backends disabled until they're enabled by default again upstream, considering the options: a) Adding local USE flags for them I think ideally, those backends should be enabled by default, when they are ready. Adding local flags now would mean they will be dropped at some point in the future; a bit confusing. b) Enabling them now It could lead to breakage later if other packages start to rely on those APIs and they are changed in future cairo releases. We have experienced that kind of problems with other packages that deliberately announce that their APIs are not frozen yet. Until then, people can test those via EXTRA_ECONF, or other ways. Anyway, that's just my opinion and I don't claim to have the final decision on what happens to cairo in our tree. It would be nice if cairo development released more early and more often.. :)
Optional unstable backends are pointless in our stable versions, they are not used by anything in the tree and if they were, it would be a mistake.
