[blfs-dev] Libexec WebKitGTK [Was ... r12813 ...]

Armin K. krejzi at email.com
Tue Mar 4 07:39:43 PST 2014


On 03/04/2014 02:22 PM, akhiezer wrote:
>> Date: Tue, 04 Mar 2014 09:22:52 -0300
>> From: Fernando de Oliveira <famobr at yahoo.com.br>
>> To: BLFS Development List <blfs-dev at linuxfromscratch.org>
>> Subject: Re: [blfs-dev] Libexec WebKitGTK [Was ... r12813 ...]
>>
>> Em 04-03-2014 02:17, Armin K. escreveu:
>>>
> 	.
> 	.
>>>> I am thinking of adding, after "make install":
>>>>
>>>> webkitgtk-2.2.4:
>>    rm -rf /usr/share/gtk-doc/html/webkitgtk-2.0
>>>> mv -vi /usr/share/gtk-doc/html/webkitgtk \
>>>>         /usr/share/gtk-doc/html/webkitgtk-2.0
>>>>
>>>> webkitgtk-1.10.2
>>    rm -rf /usr/share/gtk-doc/html/webkitgtk-1.0
>>>> mv -vi /usr/share/gtk-doc/html/webkitgtk \
>>>>         /usr/share/gtk-doc/html/webkitgtk-1.0
>>>>
>>>>
>>>
>>> For 3. I'd suggest the same as for python docs. Since they are developer 
>>> docs and developer should only use latest version to develop against, 
> 
> 
> No, not in the wider real-world picture: developers often maintain against
> two+ major-ver strands of a package; especially when the strands are very
> different and contain paradigm shifts (for want of a better term).
> 
> 
> Yes, they'll likely focus on the latest version within each strand; and
> often will only support particular strands (cf e.g. kernel LTS); but not
> _only_ the latest release of the latest strand.
> 
> 

Those who maintain against a stable release might already know the API
and as such it won't change. But for those who write new software often
tend to use latest API (git checkouts and such) to develop against.

Then again, in case of this package, there is no "stable" release except
the latest one - 2.2.x now. There's no longterm release at all.

More elegant solution will be to merge back 1.* and 2.* versions of
webkitgtk into one package since it's possible to build gtk+2 version of
webkitgtk from latest 2.* version, but it uses gstreamer-1.0 as opposed
to gstreamer-0.10 which 1.* uses and which some apps might require - not
that I know any of these that are in BLFS.

-- 
Note: My last name is not Krejzi.



More information about the blfs-dev mailing list