Dne 3.4.2013 18:15, Miloslav Trmač
napsal(a):
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.
See above.
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).
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.
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