[lsb-discuss] allowing apps to "register" with the system (was Re: application certification questions)

Wichmann, Mats D mats.d.wichmann at intel.com
Sat Mar 3 05:25:43 PST 2007


Ian Murdock wrote:
> We need to find solutions to this problem, and in the short
> term, or very
> few applications are going to be certifiable.
> 
> Applications need to be able to "register" with the system, even if
> its files are required to physically live in /opt. They're going
> to want to add
> executables and libraries to the default path, register desktop menus
> and Mozilla plugins, and other such things. We absolutely
> have to give them a way to do this, or the LSB simply won't be usable.
> 
> I understand the hesitation to allow apps to directly manipulate
> things outside of /opt, say, by creating symlinks or edit
> configuration files. A programmatic method a la xdg-utils is the best
> way to go here--allow apps to do these things, but make sure they all
> do things in a standard way. I believe lsb-install was trying to
> solve similar problems at 
> the system level (init scripts etc.) but ran into distribution
> pushback. 
> 
> The right approach here, rather than trying to get distros to adopt
> the solution, is to bundle it with the LSB SDK, and to make it really
> easy for app developers to bundle whatever we come up with their
> apps. Doing this with xdg-utils (Portland) is already on the fast
> track  list, and so should reviving lsb-install as part of this same
> strategy. 

I agree with all of this, and have for a long time.
We've already got one instance of a tool to do work
apps should not do directly, install-initd; xdg-utils
will make a second.  It would also certainly be nice if
we didn't end up with 27 distinct tools.

On the technical level, this is harder to build if
we bundle it.  install-initd was done purely at the
spec level, and now there are three very different
implementations, each of which ties appropriately
into the distros.  If we build it to bundle, we have
to solve the problem for every distro.  xdg-utils,
for example, took longer because of this. I'm saying
this to highlight that we may have a hard time getting
it done for 3.2.




More information about the lsb-discuss mailing list