Re: epics debian repository update

[Bill Lavender <lavender@agni.phys.iit.edu>]

On Wed, May 19, 2010 at 02:36:58PM -0500, Andrew Johnson wrote:
> On Wednesday 19 May 2010 13:55:26 Davidsaver, Michael wrote:
> >
> > I wonder if relocating the tree under '/usr/lib/epics/' (like
> > /usr/lib/gcc/) or '/opt/epics' would be more acceptable?  Though I would
> > definitely say that the long term solution is making the EPICS build
> > system more flexible with respect to filesystem layout.
> 
> The FHS suggests /opt/epics/<package> as the best location (although I admit 
> that epics is not currently a LANANA registered provider name).  See
> http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
> for what it says about /opt.  That is where I usually install the code for 
> training courses.
> 
> The FHS document also says:
>     Large software packages must not use a direct subdirectory under the
>     /usr hierarchy.
> About /usr/lib it says:
>     /usr/lib includes object files, libraries, and internal binaries that
>     are not intended to be executed directly by users or shell scripts.
> this /usr/lib/epics would not be appropriate for many things.

Official Debian packages never, ever go in /opt.  /usr/lib/epics might work.
For example, the various Java versions live in /usr/lib/jvm.  But you would
still be expected to put symlinks, or wrapper scripts, or some such in
/usr/bin, /usr/include, /etc, ... so that user commands could still work
without /usr/lib/epics in the PATH.  The only way to know is to try to
submit it for inclusion in the Debian repositories.  Carlo Segre could
probably help you with this process.  However, for a package as big as
EPICS, be prepared to deal with month and months and months of arguments
with the Debian developers and community about how things should be done.

Bill Lavender