# Pawel Hajdan jr (13 Nov 2013) # Masked for removal in 30 days. Does not have stable # API resulting in compile breakages in reverse # dependencies. Combined with short release cycle # (6 weeks) this makes it pretty much unusable as # a shared library. See bug #417879, bug #420995, # bug #471582, bug #477300, bug #484786, bug #490214. # Also, the following discussions: # - http://thread.gmane.org/gmane.linux.gentoo.devel/88222 # - http://thread.gmane.org/gmane.linux.gentoo.devel/88811 dev-lang/v8All packages depending on shared v8 library are now either bundling it or are masked.
This is obviously a quite controversial change. People are opposed to bundling libraries for good reasons. I'd like to make it clear that I'm also strongly in favor of using system libraries when possible. I'm also pragmatic though: in case of v8 this resulted in multiple bug experienced by users - just see the links above. With the API of v8 changing every 6 weeks and security fixes being pushed every now and then, these other packages depending on v8 just don't keep up.
Now the v8 team has made some nice improvements, as you can see on https://code.google.com/p/v8/wiki/Source:
V8 public API (basically the files under include/ directory) may change over time. New types/methods may be added without breaking existing functionality. When we decide that want to drop some existing class/methods, we first mark it with V8_DEPRECATED macro which will cause compile time warnings when the deprecated methods are called by the embedder. We keep deprecated method for one branch and then remove it. E.g. if v8::CpuProfiler::FindCpuProfile was plain non deprecated in 3.17 branch, marked as V8_DEPRECATED in 3.18, it may well be removed in 3.19 branch.Indeed I see V8_DEPRECATED being used in new v8 changes instead of removing APIs immediately. I heard sometimes they need to remove things immediately anyway, when some APIs are inherently buggy and lead to memory errors like leaks or double-frees.
Ideally I'd like to see a longer grace period for removal of APIs (not just one release, since it's only 6 weeks). Then maybe ABI stability in the scope of one release could become a consideration. The consistent usage of V8_DEPRECATED will for sure lead to more data about how much more effort is now needed to maintain the V8 API. If it turns out to be manageable, I hope to see these further improvements being tried.
By the way, with ffmpeg/libav we're pretty much in a very similar situation: Chromium uses bleeding-edge ffmpeg code, and other packages just can't keep up with API updates. Sometimes the APIs Chromium depends on are not part of any ffmpeg/libav release: Chromium developers actively contribute to upstream ffmpeg codebase and it's reasonable to iterate quickly instead of waiting for a release. I think even Fedora has exceptions for bundling libraries in such circumstances.
I don't expect this post to appease most people from the packaging community. This is just stating where we currently are. Maybe having some more stable layer that could be added on top of Chromium codebase in a manner similar to Ozone-Wayland would be one way. Still, that'd be a considerable engineering effort, mostly to keep old things working rather than developing the future. I think it has some value, the main question is just what to do with limited time developers have.
I'm experimentally enabling comments for this post - feel free to share your thoughts.