| 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 | 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 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: epics debian repository update |
| From: | Michael Davidsaver <[email protected]> |
| To: | "J. Lewis Muir" <[email protected]>, EPICS Tech-Talk <[email protected]> |
| Date: | Thu, 20 May 2010 09:23:51 -0400 |
On 5/19/10 1:29 PM, Davidsaver, Michael wrote:
[...]Hi, Michael.
So what happens if you make another release this year?
OK. Sorry, I don't know anything about Debian's package management system.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'.
So why not name the release nsls2-epics-10 where the 10 represents
major.minor of your release version number w/ the dot removed?
[...]
[...]At this point, I'm not using your Debian packages so I wouldn't want you
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)?
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.
[...]
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.
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.