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: Michael Davidsaver <mdavidsaver@bnl.gov>
To: "J. Lewis Muir" <jlmuir@anl.gov>, EPICS Tech-Talk <tech-talk@aps.anl.gov>
Date: Thu, 20 May 2010 09:23:51 -0400
On 05/19/10 15:39, J. Lewis Muir wrote:
On 5/19/10 1:29 PM, Davidsaver, Michael wrote:
[...]
Hi, Michael.

So what happens if you make another release this year?

Truth be told I'm banking on the LHC creating a black hole to swallow the Earth before then :)


Also, I hope to come up with a better set of names.

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'.
OK. Sorry, I don't know anything about Debian's package management system.

So why not name the release nsls2-epics-10 where the 10 represents
major.minor of your release version number w/ the dot removed?

When fixing bugs in or backporting packages to a release the release name generally appears in the version (ie 3.14.10-10+lenny0 or 3.14.10-20~lenny0) so the name can't include '-' or anything else which has special significance in .deb file names (~+._).


[...]
[...]
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)?
At this point, I'm not using your Debian packages so I wouldn't want you
to do anything to accommodate me. But I have a machine where I have two
versions of EPICS Base and synApps installed because I have some IOCs
that build against one version of EPICS Base and synApps and others that
build against another version of EPICS Base and synApps. In this case,
if I was to use your packages, I'd want the ability to install different
versions side-by-side.

You are not the only one with this request. Since I don't have a good solution yet I have errored on the side of less work for me...


[...]
I'm not sure what you're saying here. Are you concerned about the bug
fix "install updates" situation? For EPICS Base it won't work because
EPICS Base does not use the major.minor.bug version scheme. For EPICS
Base, the package would need to be named epics-base-31411 or whatever.
But given what you said above, this is not the real problem you're
trying to deal with.

Let me ask a question. Say you have synApps versions 5.4, 5.5, 5.6 and Base versions 3.14.10, 3.14.11. How many copies of libasyn.so do you want? Would you be happy with three where 5.4 depends on 3.14.10 while 5.5 and 5.6 depend on 3.14.11? Or would you also want synApps 5.4 built against 3.14.10? Would you want all nine possible combinations?


This is the proliferation I am worried about. I know it has happened at some sites. Though I wonder if this situation arises out of a real need, or rather from the lack of tools for dependency tracking?

Anyway, if I'm understanding your situation correctly, maybe a better
approach would be to use a single number or word in the package name
(e.g. edm-0) and then somewhere else you document what that 0 means
(e.g. edm-0 = edm 1-12-29 compiled against EPICS Base 3.14.11). You'd
have a lot of package variants, but I think it could handle all the
possible dependency combinations you want to support.

I am considering this. It seems like a manageable level of complexity. The question is if this is enough?



Michael



Replies:
Re: epics debian repository update J. Lewis Muir
References:
epics debian repository update Davidsaver, Michael
Re: epics debian repository update J. Lewis Muir
RE: epics debian repository update Davidsaver, Michael
Re: epics debian repository update J. Lewis Muir

Navigate by Date:
Prev: Re: epics debian repository update Michael Davidsaver
Next: Archiver Survey Question Ernest L. Williams Jr.
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: Re: epics debian repository update J. Lewis Muir
Next: Re: epics debian repository update J. Lewis Muir
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 ·