Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: epics debian repository update
From: "J. Lewis Muir" <jlmuir@anl.gov>
To: EPICS Tech-Talk <tech-talk@aps.anl.gov>
Date: Wed, 19 May 2010 10:18:20 -0500
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)?

You're basically creating a package that includes (or depends on) a
bunch of other packages.  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.

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.

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.

Lewis

-- 
J. Lewis Muir
Software Engineer
IMCA-CAT

Replies:
Re: epics debian repository update Bill Lavender
RE: epics debian repository update Davidsaver, Michael
References:
epics debian repository update Davidsaver, Michael

Navigate by Date:
Prev: epics debian repository update Davidsaver, Michael
Next: Re: epics debian repository update Bill Lavender
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: epics debian repository update Davidsaver, Michael
Next: Re: epics debian repository update Bill Lavender
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·