Experimental Physics and Industrial Control System
|
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|