[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:       Hedayat Vatankhah <hedayat.fwd () gmail ! com>
Date:       2015-02-20 8:17:13
Message-ID: 54E6EAB9.1080609 () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


/*Ralf Corsepius <rc040203@freenet.de>*/ wrote on Mon, 16 Feb 2015 
17:17:32 +0100:
> On 02/16/2015 05:10 PM, Martyn Foster wrote:
>>
>>
>> On 16 February 2015 at 15:12, Kevin Kofler <kevin.kofler@chello.at
>> <mailto: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).
> I don't buy this argument wrt. Fedora.
>
> Fedora is a rapid moving, forward looking distro, in which such 
> regressions should be fixed and not be worked around by compat-libs.
>
> Ralf
>
>

I guess the main point is missed completely. The main proposal is not 
mainly about compatibility. It's about providing latest development 
libraries in stable releases for *user* consumption (not for distro 
one). Also, the compatibility package is solely provided for user 
consumption; *no* Fedora package should be built against it (unless it 
happens already).

There are some arguments against providing such thing in Fedora, but if 
someone wants to install two versions of the same library (e.g. 
installing the latest version for development while having default 
version for Fedora packages); he'll do it anyway. So, if such packages 
are not provided by Fedora, he will install from source. So, the user 
will install multiple versions anyway. Do you want to support him, or not?

Regards,
Hedayat

[Attachment #5 (text/html)]

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
    <div id="smartTemplate4-template"> </div>
    <br>
    <div id="smartTemplate4-quoteHeader">
      <style type="text/css">
blockquote [[ /*Mon, 16 Feb 2015 17:17:32 +0100*/ color: navy !important; \
background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; \
margin: 15 0 0 0; border-left: #1010ff 2px solid;]]

blockquote blockquote {{ /*Mon, 16 Feb 2015 17:17:32 +0100*/ color: maroon \
!important; background-color: RGB(235,235,235) !important; border-left-color:maroon \
!important}}

blockquote blockquote blockquote {{ /*Mon, 16 Feb 2015 17:17:32 +0100*/ color: green \
!important; background-color: RGB(225,225,225) !important; border-left-color:teal \
!important}}

blockquote blockquote blockquote blockquote {{ /*Mon, 16 Feb 2015 17:17:32 +0100*/ \
color: purple !important; background-color: RGB(215,215,215) !important; \
border-left-color: purple !important}}

blockquote blockquote blockquote blockquote blockquote {{ /*Mon, 16 Feb 2015 17:17:32 \
+0100*/ color: teal !important; background-color: RGB(205,205,205) !important; \
border-left-color: green !important}} </style><i><b>Ralf Corsepius <a \
class="moz-txt-link-rfc2396E" \
href="mailto:rc040203@freenet.de">&lt;rc040203@freenet.de&gt;</a></b></i> wrote  on \
Mon, 16 Feb 2015 17:17:32 +0100:</div>  <blockquote \
cite="mid:54E2181C.4080207@freenet.de" type="cite">On  02/16/2015 05:10 PM, Martyn \
Foster wrote:  <br>
      <blockquote type="cite">
        <br>
        <br>
        On 16 February 2015 at 15:12, Kevin Kofler
        &lt;<a class="moz-txt-link-abbreviated" \
href="mailto:kevin.kofler@chello.at">kevin.kofler@chello.at</a>  <br>
        <a class="moz-txt-link-rfc2396E" \
href="mailto:kevin.kofler@chello.at">&lt;mailto:kevin.kofler@chello.at&gt;</a>&gt; \
wrote:  <br>
        <br>
            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't just care about runtime.
        <br>
        <br>
            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
        <br>
            with the
        <br>
            same version (if possible, the newer one).
        <br>
        <br>
        <br>
        The requirement to work with multiple versions of a package come
        up in
        <br>
        the scientific/HPC community very frequently. Its not always
        about API
        <br>
        compatibility, sometimes exact numerical reproduction is
        required which
        <br>
        isn't preserved even between minor versions (i.e. an OS update).
        <br>
      </blockquote>
      I don't buy this argument wrt. Fedora.
      <br>
      <br>
      Fedora is a rapid moving, forward looking distro, in which such
      regressions should be fixed and not be worked around by
      compat-libs.
      <br>
      <br>
      Ralf
      <br>
      <br>
      <br>
    </blockquote>
    <br>
    I guess the main point is missed completely. The main proposal is
    not mainly about compatibility. It's about providing latest
    development libraries in stable releases for *user* consumption (not
    for distro one). Also, the compatibility package is solely provided
    for user consumption; *no* Fedora package should be built against it
    (unless it happens already).<br>
    <br>
    There are some arguments against providing such thing in Fedora, but
    if someone wants to install two versions of the same library (e.g.
    installing the latest version for development while having default
    version for Fedora packages); he'll do it anyway. So, if such
    packages are not provided by Fedora, he will install from source.
    So, the user will install multiple versions anyway. Do you want to
    support him, or not?<br>
    <br>
    Regards,<br>
    Hedayat<br>
  </body>
</html>


[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] 

Configure | About | News | Add a list | Sponsored by KoreLogic