Re: epics debian repository update

["J. Lewis Muir" <jlmuir@anl.gov>]

On 5/19/10 1:29 PM, Davidsaver, Michael wrote:
>> -----Original Message-----
>> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
>> bounces@aps.anl.gov] On Behalf Of J. Lewis Muir
>> Sent: Wednesday, May 19, 2010 11:18 AM
>> To: EPICS Tech-Talk
>> Subject: Re: epics debian repository update
>>
>> 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)?
> 
> 2010
> 
> Just to be clear.  I'm not happy with this name, but can't think of
> anything better just now :)  Famous people in control systems?

Hi, Michael.

So what happens if you make another release this year?

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

>> 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.
> 
> Does "mega port" mean the same thing as "meta-package" (empty pkg w/
> specific dependencies)?

Yes.

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

As far as where to draw the line, I think you'd have to make every
package capable of being installed beside itself.  It would probably be
a fair amount of work if you intend for files to be installed into
standard Debian file system locations.  So, for example, instead of
caput getting installed as caput in a bin directory, now it needs to be
called caput31410 or caput31411 or whatever.  You could have a "default"
symbolic link from caput31411 to caput so that executing caput works as
expected.  Any desire to invoke a particular version of caput would need
to invoke caput with the caput31411 name.

Maybe the libraries could work out-of-the-box if the names include the
version number, but I would bet you'd run into problems here too.

> Because there can be one version of a package installed the package name
> must contain the version number.  For example the edm package name would
> become 'edm3.14.10'.

?  I don't think you want to encode the version of a dependent package
in the name of a package that depends on it.  The problem is that the
package can easily depend on more than one package and now your naming
scheme is broken.

> The worst case for me is the RTEMS versions of the driver packages
> (rtems4.9-iocstats3.14.10-mvme3100).

This is exactly why you don't want to encode the version of dependent
packages in your package name.  The name can get crazy long.

But maybe this is where we start to see a difference between a package
management system that works w/ precompiled packages vs. a "ports"
system where the dependency choices can be made at compile time.

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.

But I'm not an expert here -- maybe there's a much better way than what
I'm thinking.

> So far my "escape hatch" in discussions about this has been to suggest
> the use of 'chroot' and virtual machines.

I guess that might work, but it seems like a big headache.  If you're
willing to do that, though, then you are not installing into the
standard Debian file system locations.  If you're willing to go away
from that, then you could potentially install your packages under
/opt/package-X where package is the package name and X is the number or
word which maps to a specification of what exactly that package is (as
described above).  Then you would just need to set your environment
variables and paths to use the desired packages.

>> 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.
> 
> This is strictly by Python version.  It would be (fairly) reasonable to
> do this for only Base versions, but I'm not sure that Base releases are
> the driving force in most shops.  I found myself delaying the upgrade
> from Base 3.14.10 to 3.14.11 until a synapps release supported it.

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.

Lewis

-- 
J. Lewis Muir
Software Engineer
IMCA-CAT