[IAEP] Sugar platform overview

[Aleksey Lim]

On Wed, Jan 07, 2009 at 12:14:29PM -0500, Bernie Innocenti wrote:
> (why not cc sugar-devel@ too?)
> 
> Aleksey Lim wrote:
> > On Sat, Jan 03, 2009 at 11:23:40PM -0500, Bernie Innocenti wrote:
> >> Aleksey Lim wrote:
> >>> in fact, my concern is not about "distributing binaries" but about something
> >>> that is more systematic:
> >>> http://lists.sugarlabs.org/archive/iaep/2008-December/003422.html
> >> I see... Seems like a good idea.  EXCEPT that I wouldn't want us to
> >> invent yet another file format for specifying dependencies when we
> >> could just as easily write a script to convert the ativity.info files
> >> or spec files into any other package format.
> > 
> > in fact, there are two kinds of dependencies:
> > - jhconvert's xml files (only for glucose/fructose)
> > - honey activities that could be included to jhconvert only by changing status
> >   from honey to fructose, theirs format is (at least for me) - parsing/running
> >   sources
> 
> jhbuild is quite a complicated machinery that few developers are
> comfortable with.
> 
> Now that the bulk of Sugar is in all major distributions, we'd better
> not require new activity developers to learn their way through jhbuild
> in order to contribute useful code.  So I think we'd better keep
> jhbuild to a minimum, and perhaps just add meta-dependencies inside
> the activity.info files.
> 
> The normal workflow for an activity developer would be as easy as
> installing the core Sugar packages from their distro and then run
> their activity without building anything else.
>
> > packager(disto packager, specific-distro packager like soas, feature
> > activities.sl.o's packager) should manage them all
> 
> Have you seen http://addons.sugarlabs.org?  With an update API, it
> might *help* solve the problem of delivering all activities to all
> distros.
> 
> Marco also has put some thought into it.
> 
> 
> > I think it needs in 3rd level of dependencies and not only dependencies -
> > full meta info about sugar components:
> > 
> > - there is need in aliasing (the same package has different names in
> > various
> >   distros)
> > - packager (not developer) needs in type of dependency: build_time/run_time
> >   (and at least one extra type, due to RPM's possibility to auto generate
> >   run
> >   time dependencies from build time)
> > - there is no effective way to manage several release cycles in jhbuild
> >   only dev branch
> > - dependencies from honey activities
> > 
> > thats hard to operate with these info in jhbuild and moreover jhbuild is
> > only
> > development environment
> > 
> > about inventing another file format, I use script files in jhconvert
> 

If honey activities would provide dependencies in activity.info
[addons.s.o] could use them directly, but even in that case [addons.s.o] will
benefit from [meta-db]: installing non-sugar dependencies
(xulrunner/csound/...) - [meta-db] could suggest proper native package (or
offer it to download from [addons.s.o])

btw, [addons.s.o] also needs some kind of "db" to collect info about activities,
why not use [meta-db] through proper [various backends]

  [jhbuild] >>> [meta-db] <<< [non-core activitie]
                    V                  V
                    V                  V
         [various backends] <<<>>> [addons.s.o]
                    V
                    V
          [GNU/Linux distros] ...
                    V
                    V
          [specific distros like SoaS] ...
            
-- 
Aleksey