[pkg-fso-maint] New phoneuid snapshot?

[Sebastian Reichel]

On Wed, Jun 02, 2010 at 06:51:25PM +0200, Jonas Smedegaard wrote:
> On Wed, Jun 02, 2010 at 06:04:22PM +0200, Sebastian Reichel wrote:
> >On Wed, Jun 02, 2010 at 02:52:02PM +0300, Timo Jyrinki wrote:
> >>2010/6/1 Sebastian Reichel <elektranox at gmail.com>:
> >>> About the dependencies: phoneuid sits on top, so I will have
> >>to > update all SHR packages ;)
> >>
> >>Would be possible to someone to fix and fill in what I just
> >>started on the wiki:
> >>
> >>http://wiki.debian.org/Teams/DebianFSO#FSO.2B-SHRstack
> 
> The wiki page has changed since then.  Historical page is at
> http://wiki.debian.org/Teams/DebianFSO?action=recall&rev=60
> 
> 
> 
> >I like the idea of creating a dependency graph :) Yours is not
> >completly correct, though.
> 
> I suspect that you are referring to the graphical graph, which I
> added inspired by above post.
> 
> 
> >1. Zhone does not belong to Phone systems, it's a UI application
> >  using the phone system.
> 
> Ah, yes, I remember this pointed out earlier on this list.  I'll
> correct that.
> 
> 
> >2. shr-frameworkd does not exist, but fso-frameworkd uses
> >  python-phoneutils in opimd
> 
> As I have tried to clarify several places, the graph only reflects
> packages in Debian Sid.  I fail to locate opimd in sid.

opimd is one of the modules of fso-frameworkd.

> Yes, shr-frameworkd is a package name invented by me.  I made it
> dotted for that reason.  The reason I added it was that I would
> expect a future package providing SHR to be named something similar
> to that - and provide the virtual package frameworkd currently
> provided only by fso-frameworkd and apparently unused anywhere
> currently.

In recent versions of the framework opimd uses the library and SHR
applications make use of it. The framework version in Debian 'main'
is very old though (== it does not use it).

> >3. Your graph is missing SHR stuff, I can add them after the
> >  other things are fixed. libframeworkd-glib and libphone-utils
> >  will be connected to them.
> 
> I would prefer if you instead worked on adding the packages to Sid :-)

I'm on it =)

> Seriously, I fear that a graph tracking both officially pacakged and
> not-yet-in-Debian packages will become too complex to maintain, and
> also would confuse users unable to locate those documented packages.

Sounds reasonable. Next SHR upload will be to unstable anyway - I
can wait :P

> >4. About fso-frameworkd, it actually provides an alternative
> >  implementation of fso-usaged, fso-deviced and fso-gsmd
> 
> Ok.  Those three packages together?  Are they equal competitors, or
> are one or the other deprecated?

well fso-frameworkd is one big python daemon consisting of multiple
modules, which are ousaged, odeviced, ogsmd, ...

FSO2 splits the big python daemon into multiple daemons. So you can
disable individual modules in /etc/frameworkd.conf and use the FSO2
implementation instead.

> >5. I think nodm, xserver-xorg-video-glamo & vala-terminal should
> >  go into another package list, since they are not connected
> >  to FSO at all
> 
> What the graph documents is dependency relations between runtime
> packages maintained by the FSO team.
> 
> I can easily delete those packages from the graph.  I would prefer,
> however, that some metapackage would connect them to the graph,
> which would then also help users IMHO.
> 
> 
> >6. intone has a link to the framework, since it automatically
> >  pauses audio when you are called
> 
> That should be fixed in package dependencies, then.  Currently
> intone to not depend on the framework.

No, since it works fine without fso-frameworkd, too, it just
suggests to install it ;)

> >Another note: In the FSO2 stack there will no longer be "config
> >alternatives" packages. The libfsoframework used by all FSO2
> >daemons to load their configuration checks /proc/cpuinfo and
> >loads the correct files shipped with the daemon.
> 
> Current graph documents reality (officially in Debian Sid).  I
> recommend to document expected future separately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20100602/d385bc1d/attachment.pgp>