[webkit-gtk] Deciding the deprecation path for WebKit1

[Emilio Pozuelo Monfort]

On 30/05/14 15:26, Alberto Garcia wrote:
> Hey,
> 
> I was also thinking about the best way to handle this in Debian, and I
> think that I agree with Kalev. I'll try to give a concrete example so
> we can see if we all have the same opinion.
> 
> Right now we have 3 version of webkitgtk: webkit1/gtk2, webkit1/gtk3
> and webkit2/gtk3, so let's consider a scenario like this:
> 
> xxxterm -> libwebkitgtk-1.0-0   -> libjavascriptcoregtk-1.0-0
> liferea -> libwebkitgtk-3.0-0   -> libjavascriptcoregtk-3.0-0
> devhelp -> libwebkit2gtk-3.0-25 -> libjavascriptcoregtk-3.0-0
> 
> I think the first two don't require any changes.
> 
> However we cannot upgrade libwebkit2gtk-3.0-25 separately because that
> would bring a new version of libjavascriptcoregtk-3.0-0. Since each
> webkit package depends on a specific version of JSC, we would have a
> conflict there.
> 
> So one way to handle this when we branch for 2.6.x is to rename
> libjavascriptcoregtk-3.0-0 to libjavascriptcoregtk-3.0-1,
> libjavascriptcoregtk-4.0-0 or something like that.

Sounds in line with what Carlos said:

"For the library I guess we could renamed it as libjavascriptcore2gtk as the
javascriptcore library of webkit2."

> Since no program(*) depends directly on JSC (all of them do it via
> webkitgtk) once we upgrade libwebkit2gtk the transition would be
> automatic.

Actually I see many things in Debian depending on libjavascriptcoregtk (and thus
linking to it). They probably do that because they link against webkit, at least
most of them (I guess that's what you meant by depending on JSC through
webkit?). So a rebuild of those packages would get them linking against the new
libJSC. We would need a transition, but it would probably be very smooth.

Regards,
Emilio