RE: epics debian repository update

["Davidsaver, Michael" <mdavidsaver@bnl.gov>]

Hello Bill,

> One of my bosses (Carlo Segre), who is an official Debian developer,
> had one of my coworkers (Ken McIvor) develop some Debian packages of
> EPICS base for our own use.  He picked a naming scheme like this
> 
> ii  epics                                        3.14.10-1~lenny0
> the Experimental Physics and Industrial Contro
> ii  epics                                        3.14.10-1~lenny0
> the Experimental Physics and Industrial Contro
> ii  epics-source3.14                             3.14.10-1~lenny0
> Sources for EPICS
> ii  libepics3.14                                 3.14.10-1~lenny0
> shared libraries used by EPICS clients
> ii  libepics3.14-dbg                             3.14.10-1~lenny0
> debugging symbols for the shared libraries use
> ii  libepics3.14-dev                             3.14.10-1~lenny0
> development files for the EPICS libraries
> ii  medm                                         3.1.3-1~lenny0
> the Motif Editor and Display Manager (MEDM)
> 
> with the version numbers of the packages indicating which version of
> EPICS they were for rather than using the name of the package for
that.
> That is the normal Debian way of handling such things.

This is quite close to what I am doing except I don't have a source
package and am not using backport style (~lenny0) version numbers.
Also, the Base source package has a build dependency on all the RTEMS
stuff, but when I have time I am planning on splitting that into a
separate source package.

> Carlo has said that he would strongly prefer to be a sponsor for
> Michael Davidsaver's packages in the Debian repositories, rather than
> continue to maintain his own versions.  However, for EPICS packages
> to be accepted into the Debian repositories, they must obey Debian
> standards.  In the EPICS case, this mostly affects the naming of
files.
> Thus, in Carlo and Ken's packages for EPICS base, you end up with
> filenames like this:
> 
>     /usr/bin/caget
>     /usr/bin/caput
>     /usr/sbin/caRepeater
>     /usr/include/epics/cadef.h
>     /usr/include/epics/errlog.h
>     /usr/include/epics/tsDefs.h
>     /usr/lib/libCom.so
>     /usr/lib/libca.so
> 
> If you try to get packages accepted into Debian, you will find that
the
> Debian community will not _care_ that EPICS has decades worth of
> history
> in using a different filesystem layout.  They can be quite
intransigent
> about such things.

The practical problem is the EPICS build system, which needs the special
layout.  I had considered unilaterally moving things to the standard
prefix/{bin,include,lib} locations, but was talked out of it.

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.

> 
> If you want to see what a Debianized filesystem layout would look
like,
> take a look at Carlo's repository here:
> 
>     http://debian-xray.iit.edu
> 
> Once again, this only includes EPICS base and MEDM.  I have _no_ idea
> what they would do to things like IocCore and SynApps.

The difficultly is cross compiling for RTEMS.  I'm not sure if it will
work out in the long term, but I have had positive feedback from the few
people who have used it.


Thanks,

Michael Davidsaver
NSLSII Controls Group
Brookhaven National Lab
(631) 344-3698