LSARC/2009/250 - Firefox 3.0.x on Solaris 10

[Brian Cameron]

Margot:

> What was the resolution to Brian Cameron's GSteamer needing GLib
> 2.12 or newer?  It looks like this project is integrating version 
> 2.14.4.  Can GStreamer use that? If so, should the interface stability
> be consolidation private?  Or, has it been determined that all these
> libraries are truly private?

Just to reiterate what I said in the meeting.

GLib 2.14.4 (or any version 2.12 or later) would be fine for
backporting GStreamer 0.10 to Solaris 10.

It still is not clear if backporting GStreamer 0.10 is something that
will be done, but if the decision is made to do so, then it would
obviously make things easier if this GLib 2.14.4 library could be used.

It would be good to clarify what the interface stability level of these
GNOME base libraries will be.  If they are private, will it be possible
to get a contract to use them for GStreamer 0.10 if needed?

Brian


> -------------------------------+------------------+---------------------------------+ 
> 
> |/usr/lib/gnome-private/glib-2.0   | Project private | Project private 
> glib libraries  |
> |/usr/lib/gnome-private/libglib*.so|             | version 
> 2.14.4                
> 
> Thanks
> Margot
> 
> 
> On 05/13/09 10:00, John Fischer wrote:
>> All,
>>
>> Actually, I have set the timer for Friday, May 15th, 2009, COB PST.
>>
>> Thanks,
>>
>> John
>>
>> John Fischer wrote:
>>> All,
>>>
>>> Attached please find the updated proposal.  I have reset the timer for
>>> Wednesday May 20th, 2009.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> John Fischer wrote:
>>>> All,
>>>>
>>>> I am putting this case into need spec status to allow the project team
>>>> to produce a new specification that addresses the sharing of the Gnome
>>>> libraries and installation locations.  Once this is done I will restart
>>>> the timer appropriately.
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>> Abhijit Nath wrote:
>>>>> Alan/John,
>>>>>  Yes, it is a mistake. We'll shift all the private libraries/ 
>>>>> Firefox 3.0.x libraries in "/opt/firefox3".
>>>>> You are also correct about the LD_LIBRARY_PATH. We'll modify the 
>>>>> one pager and incorporate LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64.
>>>>>
>>>>> Some other frameworks' up-prive  (eg GStreamer) also need upgraded 
>>>>> gnome libraries( Refer Brian's mail). So we are in a process to 
>>>>> check the feasibility of keeping all the upgraded libraires in a 
>>>>> common place. We'll revert back asap.
>>>>>
>>>>> Thanks,
>>>>> Abhijit
>>>>>
>>>>> On 04/22/09 04:40, John Fischer wrote:
>>>>>> Alan,
>>>>>>
>>>>>> I totally missed the /opt/firefox and /opt/sfw issue.  Thanks for
>>>>>> catching that one.
>>>>>>
>>>>>> I'll let the project team address these issues.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> Alan Coopersmith wrote:
>>>>>>> John Fischer wrote:
>>>>>>>> This project proposes to back port Firefox 3.0.x from Nevada to a
>>>>>>>> Solaris 10 Update release which is a Patch release of Solaris.  
>>>>>>>
>>>>>>> Is it integrating into the update release or shipping as a separate
>>>>>>> web download running on top of the update release?   (/opt would be
>>>>>>> wrong for the integrated case, right for the unbundled case).
>>>>>>>
>>>>>>> Is this intended to replace or supplement Firefox 2.x?
>>>>>>>
>>>>>>> The one-pager references both /opt/firefox3 & 
>>>>>>> /opt/sfw/lib/firefox/ - can
>>>>>>> we assume /opt/firefox3 is correct since /opt/sfw is reserved for 
>>>>>>> the
>>>>>>> Solaris Companion CD?
>>>>>>>
>>>>>>>> All the plugins are spawned by firefox-bin. So, LD_LIBRARY_PATH
>>>>>>>> environment variable will be set to /opt/sfw/lib in run-mozilla.sh
>>>>>>>
>>>>>>> This also seems incorrect - should this refer to the 
>>>>>>> /opt/firefox3/lib
>>>>>>> directory or are you importing/depending on libraries from the 
>>>>>>> Companion CD?
>>>>>>>
>>>>>>> (Also, in the unavoidable cases in which you must use 
>>>>>>> LD_LIBRARY_PATH-type
>>>>>>>  variables, you should always use LD_LIBRARY_PATH_32 or 
>>>>>>> LD_LIBRARY_PATH_64
>>>>>>>  to avoid breaking programs of the other wordsize.)
>>>>>>>
>>>>>>> Are the library upgrades incompatible?   Is there no way they can be
>>>>>>> shipped as updates to the existing public libraries in /usr/lib ?
>>>>>>>
>>>>>>> For the brand new libraries, like cairo & dbus, is there any 
>>>>>>> architectural
>>>>>>> reason they must be private, or is this just a resource issue 
>>>>>>> around supporting
>>>>>>> them?
>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> opensolaris-arc mailing list
>>>> opensolaris-arc at opensolaris.org
>> _______________________________________________
>> opensolaris-arc mailing list
>> opensolaris-arc at opensolaris.org
> 
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org