EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: epics debian repository update
From: "J. Lewis Muir" <[email protected]>
To: EPICS Tech-Talk <[email protected]>
Date: Thu, 20 May 2010 10:44:07 -0500
On 5/20/10 8:23 AM, Michael Davidsaver wrote:
> 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?

Hi, David.

I guess ideally I'd want six copies of libasyn.so simply because it
gives me the most flexibility.  But as with many things, more
flexibility often comes at the cost of more complexity.

I only see six possible combinations:

1. synApps 5.4 + EPICS Base 3.14.10
2. synApps 5.4 + EPICS Base 3.14.11
3. synApps 5.5 + EPICS Base 3.14.10
4. synApps 5.5 + EPICS Base 3.14.11
5. synApps 5.6 + EPICS Base 3.14.10
6. synApps 5.6 + EPICS Base 3.14.11

Whether I'd actually need this in practice, I don't know -- probably
not.  It could be that the scenario you describe of synApps 5.4 w/ EPICS
Base 3.14.10 and synApps 5.5 and 5.6 with EPICS Base 3.14.11 would be
sufficient.  If that was all that was available, I might just choose to
go along with it and say to myself: synApps 5.5 and 5.6 go w/ EPICS Base
3.14.11 so if I upgrade to synApps 5.5 and 5.6, I *must* upgrade to
EPICS Base 3.14.11.  This would probably work OK for me.

One other thing that's an issue here for synApps is that I find myself
upgrading individual modules in synApps to fix bugs.  I would wish that
a new version of synApps would get released for bug fixes, but it
doesn't (or at least hasn't in the past).  So I would say you'd need to
be watching the modules included in synApps and upgrade them in whatever
synApps package you maintain as bug fixes.  This is obviously more work
for you.

> 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?

For me the set has stayed relatively small, but I only have a few IOCs
to manage.  So for me I probably don't need the proliferation.  Right
now, I have the following:

1. synApps       5.5   + EPICS Base 3.14.11
2. synApps       5.4.1 + EPICS Base 3.14.10
3. synApps-devel 5.4.1 + EPICS Base 3.14.10
4. synApps       5.2   + EPICS Base 3.14.8.2

The synApps-devel 5.4.1 is a build of synApps 5.4.1 which I use for my
test IOC.  I track down bugs or test upgrading certain synApps modules
in synApps-devel 5.4.1 before pushing the changes to synApps 5.4.1.

If there is a problem in EPICS Base that I need to track down, I can end
up w/

5. synApps-devel 5.4.1 + EPICS Base-devel 3.14.10

As I upgrade IOCs to new versions of synApps and EPICS Base, the older
versions get removed.

>> 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?

I'm certain it is enough.  But it can definitely get complex and
confusing.  From the name, you can't tell what you have installed.
That's lame.  And depending on how many combinations you have, you might
even need some kind of database and tool for extracting the right
versions of everything in order to build your packages.

Lewis

Replies:
Re: epics debian repository update Pete R. Jemian
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
Re: epics debian repository update Michael Davidsaver

Navigate by Date:
Prev: Archiver Survey Question Ernest L. Williams Jr.
Next: Re: epics debian repository update Pete R. Jemian
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: epics debian repository update Michael Davidsaver
Next: Re: epics debian repository update Pete R. Jemian
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·