<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 4, 2013 at 3:16 PM, Vít Ondruch <span dir="ltr"><<a href="mailto:vondruch@redhat.com" target="_blank">vondruch@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Dne 3.4.2013 18:15, Miloslav Trmač
napsal(a):<br>
</div><div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Apr 3, 2013 at 5:02 PM, Vít
Ondruch <span dir="ltr"><<a href="mailto:vondruch@redhat.com" target="_blank">vondruch@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Dne 3.4.2013 15:59, Miloslav Trmač napsal(a):<br>
</div>
<div>
<blockquote type="cite">
<div dir="ltr">On Wed, Apr 3, 2013 at 3:22 PM, Vít
Ondruch <span dir="ltr"><<a href="mailto:vondruch@redhat.com" target="_blank">vondruch@redhat.com</a>></span>
wrote:<br>
<div class="gmail_extra">... and now, can we be
specific? No handwaving, how would parallel
installation _actually_ benefit you? How
would the new system look like and work?<br>
<div class="gmail_quote"> <br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Now, there
comes security fix for Rails. Typically it
impacts every stable Rails branch, i.e. it
should be applied to two packages. But you
already denied me to use cherry-pick
straight forward, since I am not working
with one package/repository but with two
packages. So again more work then it
necessarily needed to be.<br>
</blockquote>
<div><br>
</div>
<div>I can't see that parallel installation
would help. Because there would be one git
repo for all versions? That's orthogonal to
having parallel installation of RPMs.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
Yes, they would be in one git repo with single
maintainer (or group of maintainers).</div>
</blockquote>
<div><br>
</div>
<div>AFAICS that is a Fedora dist-git concern that is
completely unrelated to parallel installation. Fedora
dist-git could support a single git repo for multiple
packages (with different names) without rpm supporting
parallel installation.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
Since .spec file is named the same as package, then you cannot merge
straight forward the changes from one package into another.</div></blockquote><div><br></div><div>That is again a Fedora policy, not a RPM requirement.<br></div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Actually then somebody comes and he
things that he doesn't need just Rails 3.0, but he
needs specifically Rails 3.0.5, so he well do another
new package rails305. You cannot stop this explosion
of various versioned modules.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, you cannot. How is that different in the case
where rpm supports/doesn't support parallel installation?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
There might be defined upgrade path, i.e. you might be able to
define that your branch is for Rails 3.0. In RubyGems, we would
define it as as ~> 3.0.0 dependency [1].<br></div></blockquote><div><br></div><div>Now I can define it using the package name, and even modify it later using Obsoletes:/Provides:.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<div>I can't see that parallel installation
would help. We need to create and maintain
as many packages as users require in either
case.</div>
</div>
</div>
</div>
</blockquote>
</div>
It would help, since I could focus on packaging new
rails version instead of fixing compatibility issues of
current applications in Fedora with the framework they
use.</div>
</blockquote>
<div><br>
</div>
<div>The two are again, AFAICS, completely orthogonal to
parallel installation support. Instead of fixing
compatibility issues the current applications could just
depend on rails23 or something. Not having parallel
installation does not automatically compel anyone to port
applications; this is primarily determined by Fedora
policy/preference and Fedora tooling, not rpm limitations.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
You cannot think about parallel installation without broader scope.
You might find a lot of orthogonal things in this issue. Something
is RPM issue, something else YUM, something else Fedora policies.
This gives always freedom to claim that it could be done
differently, not in my component etc.<br></div></blockquote><div><br></div><div>Well, sure, what Bohuslav said. Some people want Fedora to accept such RPM packages, some people want RPM support, some people might even want Fedora to ship unmodified gems/jars/eggs without RPM.<br>
<br></div><div><br>As you probably already know, there is fairly strong resistance against Fedora shipping many versions because some of as feel that we wouldn't be able to maintain them properly.<br><br>That doesn't prevent us from discussing RPM features that Fedora wouldn't use (but might be useful for coprs and RHEL). It also doesn't prevent us from discussing running of unmodified upstream packages on a Fedora system. But we need to distill what the goals of the discussion and the _actual requirements_ are.<br>
<br>If you need Fedora policy to support multiple versions, and don't care about RPM, please say so.<br></div><div>If you need RPM to support multiple versions, and don't care about Fedora policy, please say so (and suggest practical semantics for (yum update)).<br>
</div><div>If you need unmodified upstream deployment systems and unmodified upstream packages with minimal Fedora/RPM interference/involvement, please say so.<br></div><div>
<br></div><div>You've argued for RPM support, but it seems that the difficulties you actually encounter are related to Fedora policies, and I wanted to make that clear.<br></div><div> Mirek<br><br><br><div>P.S. I'll grant you that putting versions into the %{name} field is
unclean, but I really can't see that as a significant problem - I guess
%{name}, %{version} and %{release} could be named %{Tom}, %{Dick} and
%{Harry} for all we care and we would be able to get by (after all, we
can handle names like /bin/ls :) ).<br></div></div><div><br></div><div><br></div></div></div></div>