package, package2, package3 naming-with-version exploit

[Vít Ondruch]

Dne 3.4.2013 14:12, Florian Festi napsal(a):
> On 04/03/2013 12:58 PM, Vít Ondruch wrote:
>> 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?
> I have some difficulties believing that the only reason for this is that
> the name "rubygem-rails" was already taken. May be you can elaborate a
> bit more why getting Rails 2.3 into Fedora would have been fundamentally
> easier if the name was still available?
>
> Florian

Because it would be natural process.

Lets suppose we are in F14 timeframe and 2.3 are the newest Rails 
available and lets say we have in Fedora several Rails applications 
using Rails 2.3 API. They work just perfect to suit needs of their users.

Now, in F15 timeframe, Rails 3.0 were introduced. So we would like to 
move the packages to Rails 3.0. But what to do with the old 
applications? How to provide support for them? Note that even at this 
point, although Rails 2.3 are not actively developed, they are supported 
by upstream, so no need for upstreams to migrate your application.

Ok, if we don't want to break anything, we have two options
1) Just introduce new package rails30 and new applications can depend on it
2) Move the rails package to Rails 3.0 and reintroduce rails23 
compatibility package

That looks quite simple, but you doesn't count that what is called Ruby 
on Rails is collection of 40 packages (the number vary from version to 
version, but tends to increase), which would need to be re-reviewed, 
although they were just perfect moment ago.

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. We might try to 
migrate some applications to Rails 3.0 and propose patches to upstream, 
but considering this, it is already too much 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.

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. 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.

So please, don't allow this dark future. Leave the name of the package 
and the version of the package its meaning and give us tools to allow 
parallel installation and easy migration between various versions of 
packages.

I am pretty sure it will not be today, nor tomorrow, but I'd like to see 
that you acknowledge that this is issue and one day, it will be solved.

Thank you.


Vít