[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Proposal to (formally/easily) allowing multiple versions of the same library installable
From:       Martyn Foster <martyn.foster () gmail ! com>
Date:       2015-02-16 16:10:11
Message-ID: CAEmJ73-WaOvtu3PrJ6yMRKBiK-ww2H8iQUb5fFRL7=DGVzbnvw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On 16 February 2015 at 15:12, Kevin Kofler <kevin.kofler@chello.at> wrote:

> Christopher Meng wrote:
> > Maintaining several version of the same library is not easy as you think,
> > basically once a developer wants to install version X while then another
> > people want to deploy things based on version Y, how to crack this nut?
> > You can't just care about runtime.
>
> Then you need to patch one or the other package to work with the same
> version. Only if that is not possible, a compatibility library can be
> considered. But we should always first try to make everything work with the
> same version (if possible, the newer one).
>
>
The requirement to work with multiple versions of a package come up in the
scientific/HPC community very frequently. Its not always about API
compatibility, sometimes exact numerical reproduction is required which
isn't preserved even between minor versions (i.e. an OS update). These
environments usually (increasingly often) use the environment-modules
package (ideally with relocatable packages) to select between libraries or
incompatible subsystems. This is more often done by admins than explicit
support from the OS packagers, but it *can* be done elegantly as part of
the packaging process if there is a will.

Fedora already uses this - admittedly in rather limited ways;

# rpm -qf  /etc/modulefiles/mpi/mpich-x86_64
mpich-3.1-4.fc21.x86_64
# rpm -qf  /etc/modulefiles/mpi/openmpi-x86_64
openmpi-1.8.3-2.fc21.x86_64

Much more comprehensive environments can be built from the methodology.

Cheers, Martyn

[Attachment #5 (text/html)]

<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 \
February 2015 at 15:12, Kevin Kofler <span dir="ltr">&lt;<a \
href="mailto:kevin.kofler@chello.at" \
target="_blank">kevin.kofler@chello.at</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span \
class="">Christopher Meng wrote:<br> &gt; Maintaining several version of the same \
library is not easy as you think,<br> &gt; basically once a developer wants to \
install version X while then another<br> &gt; people want to deploy things based on \
version Y, how to crack this nut?<br> &gt; You can&#39;t just care about runtime.<br>
<br>
</span>Then you need to patch one or the other package to work with the same<br>
version. Only if that is not possible, a compatibility library can be<br>
considered. But we should always first try to make everything work with the<br>
same version (if possible, the newer \
one).<br><br></blockquote><div><br></div><div>The requirement to work with multiple \
versions of a package come up in the scientific/HPC community very frequently. Its \
not always about API compatibility, sometimes exact numerical reproduction is \
required which isn&#39;t preserved even between minor versions (i.e. an OS update). \
These environments usually (increasingly often) use the  environment-modules package \
(ideally with relocatable packages) to select between libraries or incompatible \
subsystems. This is more often done by admins than explicit support from the OS \
packagers, but it *can* be done elegantly as part of the packaging process if there \
is a will.</div><div><br></div><div>Fedora already uses this - admittedly in rather \
limited ways;</div><div><br></div><div><div># rpm -qf   \
/etc/modulefiles/mpi/mpich-x86_64</div><div>mpich-3.1-4.fc21.x86_64</div><div># rpm \
-qf   /etc/modulefiles/mpi/openmpi-x86_64</div><div>openmpi-1.8.3-2.fc21.x86_64</div></div><div><br></div><div>Much \
more comprehensive environments can be built from the \
methodology.</div><div><br></div><div>Cheers, Martyn</div><div><br></div><div>  \
</div></div></div></div>


[Attachment #6 (text/plain)]

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[prev in list] [next in list] [prev in thread] [next in thread]