> > as you might have seen more and more FSO 2.0 subsystems are ready for > > prime time, so we have to think about how configuration works for FSO > > 2.0. Until now I used the same method as in FSO 1.0, which is having > > it lumped all together in one config file. For FSO 2.0 I'm leaning > > towards changing this. The benefit I see from one configuration file > > per subsystem is: > > > > *) promoting the fine granular usage of individual FSO subsystems, > > *) enable packagers to ship the config with the subsystem, if they > > want, *) a third reason which i forgot while writing this mail. > > > > What do you think? > > Hi, > > from the Debian point of view I can support this idea, because it > would make packaging easier :) > > How do you plan to start the different subsystems, if each subsystem > uses it's own files? Will there be a init.d script for each subsystem?
If I undrstand things correctly, mentioned "subsystems" are actually dbus services, and as such, could be started on demand bu dbus daemon itself. This may be not true for a subsystem that takes long to initialize, in which turn this subsystem should be started at system startup. Nikita _______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
