2012/1/15 Kubo Hiroshi <h-k...@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ý <ond...@sury.org> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
