RE: epics debian repository update

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

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> bounces@aps.anl.gov] On Behalf Of J. Lewis Muir
> Sent: Wednesday, May 19, 2010 11:18 AM
> To: EPICS Tech-Talk
> Subject: Re: epics debian repository update
> 
> On 5/18/10 2:24 PM, Davidsaver, Michael wrote:
> > ps. For the future, does anyone has any better ideas for a name then
> > 'epicsdeb##'?
> 
> Hi, Michael.
> 
> What does the 10 in epicsdeb10 mean?  Is that a major version number
> (1)
> followed by a minor (0)?

2010

Just to be clear.  I'm not happy with this name, but can't think of
anything better just now :)  Famous people in control systems?

> 
> You're basically creating a package that includes (or depends on) a
> bunch of other packages.

No, what I am creating is a Repository or Release/Codename.  This
differs from the behavior you get from a meta-package (empty pkg w/
specific dependencies) which I think you are referring to.

Debian package manager restricts you to only having one version of a
package installed.  So an 'epics-suite' meta-package might depend on
Base 3.14.10 and synApps 5.4.1.

You can have any number of Repositories listed in sources.list.  Each
presents one (or more) versions of a package of which only one can
installed at a time.  In this way one can take some packages versions
from 'stable' and some from 'testing'.

> I would name it just epics (renaming an
> existing epics package containing EPICS Base to epics-base).  If you
> don't like that, perhaps you could name it epics-suite (?).
> 
> You might consider how the GNOME desktop is packaged for various
> package
> management systems.  One example is MacPorts which has a gnome port (a
> port in MacPorts is like a package) for the GNOME desktop environment
> which depends on all kinds of other ports.  It's a "mega" port.  When
> one installs the gnome port, all the dependent ports required to
> install
> a useful GNOME desktop environment get installed.

Does "mega port" mean the same thing as "meta-package" (empty pkg w/
specific dependencies)?

> 
> If you need to be able to install older versions of the epics package
> or
> have more than one version of the epics package installed at the same
> time, you generally have to qualify the name of the package somehow
> (unless the package management system supports a built-in way to
> install
> a particular version or multiple versions at the same time).  I'm
> guessing you're already doing this with the 10 on the end of
> epicsdeb10.
>  This seems reasonable to me.  Using this method, you could use a
> major.minor.bug version number scheme for the epics package.  You
> append
> the major.minor version number part to the package name leaving out
the
> dot.  Then you just document somewhere what's included in what
> major.minor release of the epics package.

It was actually a conscious decision on my part not to allow multiple
versions to be installed at the same time (on the same machine).  I am
open to reconsidering it though.  My reasoning is that I don't know
where to draw the line.  Should it be just by Base version?  By synapps
version?  By EDM version?  By major version (3.14) or "minor" version
(3.14.10)?

Because there can be one version of a package installed the package name
must contain the version number.  For example the edm package name would
become 'edm3.14.10'.

The worst case for me is the RTEMS versions of the driver packages
(rtems4.9-iocstats3.14.10-mvme3100).

So far my "escape hatch" in discussions about this has been to suggest
the use of 'chroot' and virtual machines.

> 
> For example, if you had a 1.0.0 release of the epics package, the
> package name would be epics10.  The epics package gets automatically
> updated for bug version number changes.  So if you released epics
1.0.1
> (i.e. just a bug fix, not an API change), this would automatically get
> installed for the epics10 package by one's package management system
if
> one chose to "install updates."
> 
> In MacPorts, this scheme is used for the Python ports where there are
> python24, python25, python26, and python31 ports, representing Python
> 2.4, Python 2.5, Python 2.6, and Python 3.1, allowing one to install
> one
> or more of them side-by-side.

This is strictly by Python version.  It would be (fairly) reasonable to
do this for only Base versions, but I'm not sure that Base releases are
the driving force in most shops.  I found myself delaying the upgrade
from Base 3.14.10 to 3.14.11 until a synapps release supported it.


Thanks for the interest!

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