Project Looking Glass

On Fri, Nov 18, 2005 at 10:10:34AM -0800, Paul Byrne wrote:
> Apart from our updated Xserver most of our binaries are actually jar
> files so I don't think they belong in /usr/lib itself, let me give some
> more detail....
> 
> Currently for development we have everything under one directory, the
> structure looks like this
> 
> lg3d
>     ext                           Supporting jars for both core and
> bundled apps
>     ext-unbundled         Space for app specific supporting jars
>     lib                           The main platform jars and native
> .so's for X server binding
>     resources                  Images etc
>     bin                           Shell scripts to start everything
>     etc/lg3d                    Config files
> 
> For deployment the etc/lg3d directory obviously becomes /etc/lg3d and
> the scripts in bin probably belong in /usr/local/bin. For everything
> else there seem to be a number of choices, the best of which I think are

You can't install stuff to /usr/local (or to /home) at all[0], so
/usr/bin would be a better fit.

> 1)  The .so's go in /usr/lib/lg3d and everything else goes in
> /usr/share/lg3d. Apache-ant seems to follow this approach.

This sounds like the best fit to me.

> 2) The .so's and all the jars go in /usr/lib/lg3d (various sub
> directories) and the resources  go in /usr/share/lg3d

If the jars are architecture-independent, then /usr/share may indeed be
a better fit; I'm not very well qualified to speak about Java, however,
so your best bet here may be to read the Debian Java Policy.

> 3) As we are providing a window system platform we follow the precendent
> set by X and put everything (except etc) in /usr/lg3d as a sibling of
> /usr/X11R6

Ah.  We moved most of X out of /usr/X11R6 and into /usr (e.g. /usr/bin,
/usr/lib, /usr/share, /usr/include et al) for the Breezy cycle, but
unfortunately the server was still stuck there.  However, for Dapper,
we've got the last of it out.

> OpenOffice and gcj seems to have jars in both /usr/share and /usr/lib
> 
> My preference would be either 1 or 3 as it keeps the bulk of the
> components together. What do you think ?

I guess 1 sounds most attractive to me, but you don't really need to
keep all your components all in one directory with a packaging system as
much as you do when you don't have those supports.

Cheers,
Daniel

[0]: The main exception to this being when you need to install
     directories to enable user-supplied scripts to be installed, e.g.
     /usr/local/share/python/site-packages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051121/7cc221ae/attachment.pgp