5,705
edits
Changes
Jump to navigation
Jump to search
Line 24:
Line 24: + + + + − + − + + +
Platform Team/Package Management System (view source)
Revision as of 10:48, 19 December 2009
, 10:48, 19 December 2009→Work flows
To utilize Services benefits, activity developer just need to [[Activity Team/Documentation/Services/Activity Developers HOWTO|mention all services(or pure 0install feeds)]] that activity is using. Services infrastructure will provide specified services(and specified versions) for activity and will export environment variables, like LD_LIBRARY_PATH or PYTHONPATH, to activity session, so activity developer shouldn't adapt code to Services.
To utilize Services benefits, activity developer just need to [[Activity Team/Documentation/Services/Activity Developers HOWTO|mention all services(or pure 0install feeds)]] that activity is using. Services infrastructure will provide specified services(and specified versions) for activity and will export environment variables, like LD_LIBRARY_PATH or PYTHONPATH, to activity session, so activity developer shouldn't adapt code to Services.
=== Use non Sugar Platform dependencies ===
Sugar Platform could not grow endlessly and components like Qt or OO4Kids will be out of Sugar Platform list. But activities can still use such dependencies by installing them from native packaging systems and do not bundle binaries. See [[Activity_Team/Documentation/Services/Non_Sugar_Platform_Dependencies_HOWTO|Non Sugar Platform Dependencies HOWTO]] to know how to use 0install features.
=== Service developers ===
=== Service developers ===
Services could be:
Services could be:
* 3rd party applications that are not included to Sugar Platform e.g. Qt
* libraries or applications that are not intended to be included to Sucrose
* applications that were not included to all deployed Sugar Platforms e.g. gst-espeak came only from 0.84 and Services will let gst-espeak based activities work even in 0.82 environment
** could be used by few activities
** have shorter or longer release/support schedules
** just a useful way to share your library w/o bundling binary blobs
* dependencies that are specific to particular activity e.g. some python activities have C libraries, using Services, activity developer should not bundle all binaries that sugar supports but provide links to binaries that he managed to build and let Services build C libraries from sources on user side in the rest of cases
* dependencies that are specific to particular activity e.g. some python activities have C libraries, using Services, activity developer should not bundle all binaries that sugar supports but provide links to binaries that he managed to build and let Services build C libraries from sources on user side in the rest of cases