On 15/07/15 11:26, Ricardo Mones wrote: > On Tue, Jul 14, 2015 at 01:52:19PM +0200, Emilio Pozuelo Monfort wrote: >> On 14/07/15 13:37, Ricardo Mones wrote: >>> Hi Emilio, >>> >>> On Sat, Jun 27, 2015 at 05:41:23PM +0200, [email protected] wrote: >>>> Source: claws-mail >>>> Severity: important >>>> Tags: sid stretch >>>> User: [email protected] >>>> Usertags: oldlibs libwebkitgtk-1.0-0 webkit1 >>>> >>>> Hi, >>>> >>>> claws-mail depends on libwebkitgtk-1.0-0, which is deprecated in >>>> favor of libwebkit2gtk-4.0-37. claws-mail should be ported to the new >>>> webkitgtk version so we can remove the old, unmaintained one. >>>> >>>> As an intermediate step you can port claws-mail to >>>> libwebkitgtk-3.0-0, which has a similar API to libwebkitgtk-1.0-0 but >>>> is based on GTK+ 3.0. Thus you'd be porting claws-mail to GTK+ 3.0 >>>> first, using libwebkitgtk-3.0-0, and you could then port to >>>> libwebkit2gtk-4.0-37 later. But note that libwebkitgtk-3.0-0 is also >>>> deprecated. >>>> >>>> Please try to do this before the Stretch release as we're going to >>>> try to remove libwebkitgtk-1.0-0 this cycle. >>> >>> Given the age of upstream GTK+ 3.0 porting bug¹ and the effort required >>> to do such porting I doubt very much this will happen soon, unless some >>> porting guru comes out of the blue. >>> >>> ¹ http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2371 >>> >>>> We'll bump this to serious when the list of rdeps is small and we're >>>> getting ready to removing libwebkitgtk-1.0-0 completely. >>>> >>>> If you have any question don't hesitate to ask. >>> >>> Well, there's some other solutions just from the top of my head, from >>> easier to harder: >>> >>> * drop fancy plugin, which is the one introducing such dependency (and >>> leave Claws Mail users without HTML mail rendering) >>> * upstream embeds the library within the plugin (since it's going to >>> be removed it's not even an ECC) >>> * fork the library keeping API/ABI, repackage it for Debian and depend >>> on the forked one >>> >>> Since upstream is probably not happy with first one, I guess one of the >>> other two will be selected, or something better, if available. >> >> The second and third options sound like totally bad ideas to me. >> Please don't do those. For now just keep the status quo and poke >> upstream about the switch to GTK+ 3. > > Agreed, they're bad ideas, but switching to GTK+3 is not going to happen > just by poking upstream. The team is just too small and there's no real > motivation or need to do it. Those solutions were meant for the moment > when libwebkitgtk-1.0-0 is removed, not for now, don't worry :)
When that time comes, dropping the plugin is a much better option than the other too. Another option is writing an alternative plugin that uses a different library, such as libgtkhtml (which may be deprecated as well) or some other. >>> Do you have planned dates for the removal to happen? >> >> Might not happen for Stretch given the amount of rdeps at the moment. If we >> can't do it for Stretch, we'll definitely try to get rid of it for Buster. >> But >> no specific dates atm. > > Well, then there's still time for things to develop. Thanks for the > information. Yep. This is a heads up. Cheers, Emilio -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
