Dne 3.4.2013 12:26, Florian Festi napsal(a):
On 03/29/2013 10:33 AM, Bohuslav Kabrda wrote:
To me, these are very different aspects - should RPM/YUM be able to support multiple parallel versions without the naming hacks? Yes. Should Fedora as a distro support numbers of multiple versions of packages? In my opinion, we should try to keep counts of supported packages minimal, as we do now. But that doesn't really depend on _how_ we package the stuff.
This is about providing the tooling to people who actually want to maintain these more versions in their private repositories or whatever.
Sorry, but this is not how we as an upstream project think. We calculate
the benefits against the costs. The costs of breaking/changing such a
fundamental rules as "name.arch defines an update path" is extremely
high.
The only thing you get wrong is that you take a look at Fedora packages
and do some statistics. You don't see the packages which could be in
Fedora if RPM/YUM would do better job.
Just as an example, I guess everybody would welcome Redmine [1] in
Fedora (you can substitute GitLab [2] or Aeolus [3] for Redmine if you
like). It was not possible to do so for several releases of Fedora,
since Redmine was using Ruby on Rails 2.3 where in Fedora, there was
Ruby on Rails 3.x. If we would like to move to Ruby on Rails 4 in Fedora
as soon as they'll be releases, we will have actually two options (1)
forget about the upgrade of Ruby on Rails in Fedora and wait for
upstream or possible become upstream, to help with migration of the
project (2) break Redmine and every application which is using Ruby on
Rails in Fedora. Neither of these options are good options. So the
easiest solution is to not have Redmine in Fedora at all.
So now, please, could you count also the cost of missed opportunities?
Vít
[1] http://www.redmine.org/
[2] http://gitlab.org/
[3] http://www.aeolusproject.org/
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
