[pkg-fso-maint] fso: state of packaging?
Heiko Stübner
heiko at sntech.de
Mon Sep 14 19:42:09 UTC 2009
Hi,
Am Montag 14 September 2009 20:47:20 schrieb Nikita V. Youshchenko:
> > Another issue is that FSO changes everything ever now and again, and one
> > loses touch with what upstream is doing. Joachim mentioned that he "lost
> > the overlook a bit".
> >
> > I instead did not dare to look at the packages that Heiko has made
> > because I completely lost upstream. There is such a tangle of packages
> > and libraries with similar names, some of which are alternatives, some
> > of which are outdated, some of which are the future but do not work yet,
> > or break some application that everyone is using unless we update it to
> > somesuch version only found in someone's personal git plus the patch
> > posted in another mailing list a month ago. Or something like that.
> >
> > I would welcome a summary of what packages are now needed for what, and
> > I guess that it would help more than myself.
>
> Seconded.
Ok, I will try to summarise the parts that I'm working on at the moment.
As you know fso-frameworkd consists of some individual subsystems [e.g
ousaged, odeviced, ogsmd, ...] that are implemented in python. Upstream
replaces these subsystems step-by-step with in vala reimplemented versions.
The most notable one is fsousaged which replaces the similiar named original
subsystem. This was sped up by upstream as the original one had bugs that
could not easily be resolved in the python implementation.
--
So you need fso-frameworkd, fso-usaged, whatever libraries it depends on and
the config-snapshot posted here and added to the openmoko-files-config git
repository yesterday. (It deactivates ousaged and activates fsousaged instead)
--
I think the next step will be the odeviced to fsodeviced and then somewhere
the osgmd to fsogsmd transition.
For completenes sake some words about the libraries as I understand it:
- libfso-glib: it seems to be some kind of interface-definition, as it is
generated out of the xml-specification of the dbus-interface
- libfsobasics: like it says :-), basis for libfsoframework and
libfsotransport [logging and such]
- libfsoframework: plugin-handling etc.
Libraries that are in some premature states but are working for me:
- libgsm0710: gsm-protocol implementation based on some code of Trolltech
- libfsotransport: something about serial communication
- libgsm0710mux: Muxer-Implementation, needs libgsm0710
fso-abyss is simply frontend for libgsm0710mux to communicate with ogsmd until
fsogsmd is ready, which will then be linked directly against libgsm0710mux
The hardest problem is at the moment to always find stable combinations of
libraries and programms that also work with current vala in debian.
Everytime a new vala-version is released and the vala-maintainers upload it
the fso-guys have some catching-up to do for it most of the time. But when
this is done, older (e.g officially released) versions of the libraries cannot
be used anymore as they are then incompatible with the newer vala-version.
Vala seems to me to be highly volatile from version to version.
Just to ease Enricos fears: fsousaged can be deactivated any time by simply
commenting out the fsousaged and reactivating ousaged :-)
Hope this explanations helped a little bit
Heiko
More information about the pkg-fso-maint
mailing list