Dne 4.4.2013 15:47, Miloslav Trmač napsal(a):
On Thu, Apr 4, 2013 at 3:16 PM, Vít Ondruch <vondr...@redhat.com
<mailto:vondr...@redhat.com>> wrote:
Dne 3.4.2013 18:15, Miloslav Trmač napsal(a):
On Wed, Apr 3, 2013 at 5:02 PM, Vít Ondruch <vondr...@redhat.com
<mailto:vondr...@redhat.com>> wrote:
Dne 3.4.2013 15:59, Miloslav Trmač napsal(a):
On Wed, Apr 3, 2013 at 3:22 PM, Vít Ondruch
<vondr...@redhat.com <mailto:vondr...@redhat.com>> wrote:
... and now, can we be specific? No handwaving, how would
parallel installation _actually_ benefit you? How would the
new system look like and work?
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.
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.
Yes, they would be in one git repo with single maintainer (or
group of maintainers).
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.
Since .spec file is named the same as package, then you cannot
merge straight forward the changes from one package into another.
That is again a Fedora policy, not a RPM requirement.
Ok, so shall I read it an "go ahead, and propose Fedora policy change,
that although package name includes version, the .spec file should be
named without the version."?
Actually it would make sense to me. However, it makes exception from
exception, which is fail.
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.
Yes, you cannot. How is that different in the case where rpm
supports/doesn't support parallel installation?
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].
Now I can define it using the package name, and even modify it later
using Obsoletes:/Provides:.
I can't see that parallel installation would help. We need
to create and maintain as many packages as users require in
either case.
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.
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.
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.
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.
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.
I feel that we do so and we are not able to maintain it properly. So
there would not be any change in this regard.
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.
I was never speaking about unmodified upstream packages, this just
derails the discussion.
If you need Fedora policy to support multiple versions, and don't care
about RPM, please say so.
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)).
If you need unmodified upstream deployment systems and unmodified
upstream packages with minimal Fedora/RPM interference/involvement,
please say so.
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.
Mirek
That's both, RPM and Fedora plolicies and don't forget about YUM. They
are not independent.
Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
