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:
Ok, so lets say we introduce the rails23 compatibility
packages (which is IMO the better option, since the
nonversioned package should always point to newest and
greatest release), we do the reviews and we possibly double
the amount of packages. We even fix all the application
dependencies from rubygem-rails to rubygem-rails23.
OK, let's skip the re-reviews. That's obviously added work.
... 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. In one repo
you would have foo.spec file and in another foo1.spec file, so be it one
or two repositories, you would need to do the merge by yourself.
Current Rails are maintained, I don't consider to be big headache
to maintain more branches, but it gets complicated to maintain
multiple components.
Where is the difference, and more importantly how does it depend on
rpm support? AFAICS this is again a Fedora dist-git (and Fedora
package review) concern.
See above.
Yes, you might change the policy that re-reviews are not
necessary, but anyway, you'll end up with mess of packages such as
rails23, rails30, rails31, rails32, rails40 and you lost the
meaning of version.
Who cares? In what case? Is that only about the '-' character?
That is about semantics.
Package name should be the same as upstream name, there are definitely
no project such as rails23 or rails 30. So you confuse your users. And
then, there is no implied relation for such packages. There might be for
you, but it gets harder for machines. Actually rpm5 is different project
then RPM we are using in Fedora.
You loose the meaning of version field as well. Where can I found the
rails23-1.0 version of package? Why the first available version of
rails23 is -2.3.0 and the last -2.3.8, upstream does not release new
versions? That's odd. What if there will be release Rails 2.4 and
somebody even update the rails23 package to rails-2.4.0 version? And
don't tell me that this cannot happen, take look on Linux kernel which
changed its version to 3.x basically just because of fun. May be the
upstream is using string comparision for versions, so they cannot
release Rails 2.3.10 (this is btw case of Ruby, i.e. the versions must
be comparable in its string representation).
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].
Yes, still, somebody could come and do review of rails305 anyway, but it
would be visible as a exception.
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.
Actually, if packages are nonconflicting, RPM itself can install them
side by side without any issues. That would mean that RPM buys should
not be involved. So now we can blame YUM, you things that we can solve
it by policy and renaming packages. So at this point, we might say that
renaming packages is not what we want. Ok, get back to YUM, YUM would do
something but RPM is completely fine, since it can install several
nonconflicting packages, so why there should be any additional metadada
or what else might be needed, if it is possible already.
We can play this game forever.
Vít
[1] http://docs.rubygems.org/read/chapter/16#page74
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
