[DRE-maint] Bug#655896: Bug#655896: Rails depends on the wrong version of librack-ruby, which leads to a loss of data in redmine.

[Ondřej Surý]

2012/1/15 Kubo Hiroshi <h-kubo at geisya.or.jp>:
> Hi,
>
>> Hi,
>>
>> in Debian it is not responsibility of individual packages, but generaly of a packaging system.
>>
>> Unfortunatelly what you are asking is impossible to achieve. I believe it's not a bug, but a failed ruby concept of havimg versioned dependencies but no SONAMEs. Therefore there can be only one rack package installed at the time.
>
> Hmm.
>
> * The original rails insists it requires rack 1.0.1.
>
> * Actually a loss of data has occurred with the rack 1.1.0.
>
> So, the "only one rack package" should be the one whose version is 1.0.1, isn't it?

No. There's whole ecosystem of packages in Debian depending on libruby-rack:

  camping
  ironruby-utils
  libactivesupport-ruby1.8
  libactivesupport-ruby1.9.1
  libapache2-mod-passenger
  libmerb-core-ruby1.8
  librack-ruby
  libramaze-ruby1.8
  libramaze-ruby1.9.1
  libsinatra-ruby1.8
  libsinatra-ruby1.9.1
  puppetmaster
  thin1.8

which one you would decide to determine the version of rack?
The standard packaging policy is to have latest stable and it
usually works well. But with ruby it's becoming a nightmare
since it's not uncommon that API change even between minor
and patch releases :-/.

> And to achieve it, I wonder is there another way.
>
>>
>> I believe it's the source code in the package which needs fixing and not the  versioned depends.
>
> I didn't figure out which source code you are referring to.
>
> I just want to overcome the loss of data, and am willing to be convinced :-)

The source code which is causing the data loss, e.g. probably the redmine's.
Anyway the downgrade is not going to happen in the stable distribution since
it's against all policies Debian has. But small self contained fix in
the redmine
(or rails if the bug is there) may go through.

O.
-- 
Ondřej Surý <ondrej at sury.org>