my 2 cnts;
I work in/with HPC, and run into that stuff all the time, and it is
unavoidable.
Since HPCs run diskless, and boot in/from a network, we simply build a
complete new image, (and keep
the older ones around). We never even update an image, we simply build a
new one from scratch, since
an update on an existing system never works and it is easier to rebuild
a repo (at least in RHEL it is).
Libraries etc, specific to applications either get relocated, or are
merged with the OS ones on a virtual file system.
Of course that is pretty much undo-able, impractical, unaffordable to do
at home, so what I do: I use different drives with
separate installs (I use these now very inexpensive CRU data trays to
swap drives, and SSDs are really inexpensive now)
And indeed, let's not even get started on "rolling back" within an image.
containers; that's one of these things that don't seem to work
consistently yet. I know people (at work) that are working
with it, developing in it, but I have not seen it work reliably/stable
yet. It will definitely go there, but as of yet, at least
at scale, it is not working. (there are lots of issues that come down to
latency/timing and rdma issues and we don't
even use real time kernels etc. most of what I do is based on RHEL and
application specific RHEL 'flavors')
as I said, just my 2 cts,
Ron
On 4/2/20 4:14 AM, Przemek Klosowski wrote:
On Wed, Feb 19, 2020 at 1:51 AM Rafael Skodlar <ra...@linwin.com> wrote:
Think about LinuxCNC and it's packages. Using Slackware method you could
try to use different version of LCNC to see if it's good for your CNC
setup. If the new version fails (breaks your tool?) you could run
"cnc-admin script" to roll back, i.e. relink the app to previous version
and start it.
/opt/linuxcnc-v2.6/bin <- binaries or scripts
/opt/linuxcnc-v2.6/etc <- config files
...
/opt/linuxcnc-v2.7/bin
/opt/linuxcnc-v2.7/etc
...
What you suggest is not that simple. For starters, there are cross-package
dependencies, so in general you will have to carry various system libraries
required by each version. Then, modern programs use various forms of IPC,
so they need version specific versions of those IPC endpoints (things like
DBus, etc). IN the end, you can do it, but you replicate huge parts of the
OS. RedHat/Fedora tried to do Modularity, which is something like what you
propose except it turned out that you could have multi-version availability
but not multiversion installability (it was easy to switch versions, but
you could install only one). They put a lot of effort into making
dependencies work automatically, but in the end it turns out that lifecycle
management (patching/updating) is hard in a multi-version world: multiple
versions of multiple programs lead to combinatorial explosion of
dependencies and unresolvable conflicts when one program depends on ver. X
of something and another one on ver. Y. Currently Modularity is in retreat.
The technology to do that exists---containers like Docker or Podman. The
downside is that your system is now a mess of versions, and you need to
worry about patching and updating them. Containers provide a partial
solution to the Modularity problems---you can isolate such conflicts to
separate containers, but you still need to worry about lifecycle management.
If you are serious about those issues, read up on containers and
modularity---don't invent your own solutions, as a lot of people tried to
do it right and it's worth to learn from their experiences.
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
