Gabriel M. Beddingfield wrote:

>   But, if I supply extra applications/packages with my
>   device... things that are core to my OEM product...
>   is it OK to package them according to LSB?  Obviously,
>   all the packages in MeeGo Core have been installed using   LSB.

Yes, and no.

For things you add on as a device builder you can choose;
the idea of the FHS filesystem namespace rules (which are
imported into LSB and slightly expanded there because FHS
is OS-agnostic and misses some Linux conventions as a result)
is the separate three roles and keep them from stepping on
each other with their installs - (1) OS vendor, (2) ISV, 
(3) local system operator/administrator/owner, whichever term fits.
As a device builder you're perhaps some of (1) and (2) both,
and you can make sure to avoid conflicts.

On the other hand, there's no particular /need/ for the
core or profile pieces to follow the addon paths, because
they are firmly in category (1).  


> Operating system standard locations:
> 
>   If I'm writing an app that, for instance, lists all
>   the applications installed (*.desktop)... where do
>   I go to find these?  According to this, I would need
>   to `find /opt -name "*.desktop"`, and there's
>   no mention of /usr/share/applications or an LSB spec.
> 
>   What I'm getting at (to be a little more clear) is
>   that when an application NEEDS something from the
>   OS, this spec doesn't provide any information about
>   where to go.  Right now, reference to LSB is limited
>   to application binary format (ELF).[1]  It might be
>   good to appeal to more of the LSB Core[2] and even   LSB Desktop.[3]


some of that will perhaps happen but LSB, which itself refers
to several other docs, is a smaller set than MeeGo Core and too
many levels of reference means nobody will bother to follow the
references - I'm working on the idea that this spec ought to be 
a relatively complete description of what people need. Without
becoming a 1000-page doc, that is!  :)  All that subject to 
adjustment as things evolve, I guess.

_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Reply via email to