1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 22/09/13 08:17 PM, "Paweł Hajdan, Jr." wrote: |
5 |
> I'd like to get your feedback and opinion about removing shared v8 |
6 |
> library package from Gentoo. It's currently used by |
7 |
> www-client/chromium, dev-db/drizzle, dev-db/mongodb, dev-lang/v8cgi |
8 |
> and sci-geosciences/osgearth. |
9 |
> |
10 |
> net-libs/nodejs switched back to bundled v8 a long time ago: |
11 |
> |
12 |
> 25 Feb 2013; Patrick Lauer +nodejs-0.6.21-r2.ebuild, |
13 |
> +nodejs-0.8.20.ebuild: Version bump for 0.6 and 0.8 that also |
14 |
> disables shared v8 as our v8 maintainers remove all compatible |
15 |
> versions |
16 |
> |
17 |
> Some bugs for reference: |
18 |
> |
19 |
> https://bugs.gentoo.org/show_bug.cgi?id=417879 |
20 |
> https://bugs.gentoo.org/show_bug.cgi?id=420995 |
21 |
> https://bugs.gentoo.org/show_bug.cgi?id=471582 |
22 |
> https://bugs.gentoo.org/show_bug.cgi?id=477300 |
23 |
> https://bugs.gentoo.org/show_bug.cgi?id=484786 |
24 |
> |
25 |
> From mongodb upstream |
26 |
> <https://jira.mongodb.org/browse/SERVER-10282> : "compiling with |
27 |
> versions of v8 other than what is included is not currently |
28 |
> supported." |
29 |
> |
30 |
> I'd like maintainers of all packages depending on dev-lang/v8 to |
31 |
> make their packages use bundled v8 copy instead (I can file bugs |
32 |
> for that, let's discuss here whether it should be done). |
33 |
> |
34 |
> For now V8 upstream gives no guarantees about API/ABI stability |
35 |
> and actually breaks it very often |
36 |
> (<http://upstream-tracker.org/versions/v8.html>). Having a shared |
37 |
> library so closely tied to packages (which results in frustrating |
38 |
> blockers, since v8 is updated often and chromium is synchronized |
39 |
> with that) is not really much different from everyone bundling the |
40 |
> library. I'd like that to improve, but for now it's time for a |
41 |
> pragmatic solution to this IMHO. |
42 |
> |
43 |
> Paweł |
44 |
> |
45 |
|
46 |
|
47 |
FYI - Spidermonkey is in the exact same situation -- upstream develops |
48 |
with the expectation that projects will embed the code or at best |
49 |
bundle the lib. They also completely break API with every major |
50 |
version bump (ie, every 6 weeks). Fortunately they accepted patches |
51 |
that support installing multiple versions concurrently, and so I've |
52 |
started slotting it in the tree. |
53 |
|
54 |
IMO, just like spidermonkey, yes we should still try and keep libs as |
55 |
system-installed rather than bundling. Just because upstream doesn't |
56 |
think it's the "right" idea and doesn't support it, doesn't mean we |
57 |
shouldn't continue to push for this paradigm. That said, I don't know |
58 |
anything about v8 and if it would be feasible to slot it, and |
59 |
ultimately, it's going to be up to the dev's maintaining both v8 and |
60 |
its rdeps, since they're the ones that need to do the work... |
61 |
|
62 |
|
63 |
-----BEGIN PGP SIGNATURE----- |
64 |
Version: GnuPG v2.0.20 (GNU/Linux) |
65 |
|
66 |
iF4EAREIAAYFAlI/iikACgkQ2ugaI38ACPAQcQD+PicDLQX4e2TsZv5wuAKlVKGW |
67 |
rjNhGjeE4Eet/So9xqQBAJzDUp5AeiZqmRpzCxzQoi5OOorYfRnTZMDU9elgcDVP |
68 |
=CfAi |
69 |
-----END PGP SIGNATURE----- |