Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
On Fri, Jan 12, 2007 at 10:24:13AM -0600, Adam Majer wrote: While direct upgrades from sarge to lenny won't be supported, it would be more accurate to just leave the Conflicts: in (or change it to Breaks:) because the problem won't have disappeared, it'll just be less likely to be encountered. (Well, maybe ruby1.8 will be deprecated by lenny, I guess that's one possibility. :) I'm not sure about the Breaks. rails does not break the libdeve-logger, libdevel-logger breaks rails and libdevel-logger is not part of Debian after Sarge. Or does Breaks mean that Package: A Breaks: B Package: B then this indicates that package A is broken by B? Hmm, good point, I'm not sure that Breaks is symmetric. So don't mind me. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
On Wed, Jan 10, 2007 at 02:33:23PM -0600, Adam Majer wrote: Filipe wrote: This package is from sarge, but if someone has this installed in sarge and upgrades to etch, then it stay in the system. It provides the same functionality that logger.rb from libruby1.8 provides, and it has a file called application.rb that seems to get in the way of rails. This error can be reproduced by installing libdevel-logger-ruby1.8 from sarge (this package isn't in etch), and it can be installed without any dependencies problem. Well, it seems that the old logger was not part of the same source as ruby. I'm not sure if the conflicts should go to ruby unless the new ruby also has devel/logger.rb or application.rb. This doesn't seem to be the case though. Rather than a file conflict, this is a conflict of functionality; a target use for the proposed Breaks dpkg field. I think I'll just add the needed conflicts for Etch and remove it in the next upload after Etch is released. Seems like that may be the path of least resistance. While direct upgrades from sarge to lenny won't be supported, it would be more accurate to just leave the Conflicts: in (or change it to Breaks:) because the problem won't have disappeared, it'll just be less likely to be encountered. (Well, maybe ruby1.8 will be deprecated by lenny, I guess that's one possibility. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
On Fri, 12 Jan 2007, Steve Langasek wrote:
Well, it seems that the old logger was not part of the same source as
ruby. I'm not sure if the conflicts should go to ruby unless the new
ruby also has devel/logger.rb or application.rb. This doesn't seem to be
the case though.
Rather than a file conflict, this is a conflict of functionality; a target
use for the proposed Breaks dpkg field.
Yes, when breaks be out rails can use it.
I think I'll just add the needed conflicts for Etch and remove it in the
next upload after Etch is released. Seems like that may be the path of
least resistance.
While direct upgrades from sarge to lenny won't be supported, it would be
more accurate to just leave the Conflicts: in (or change it to Breaks:)
because the problem won't have disappeared, it'll just be less likely to be
encountered. (Well, maybe ruby1.8 will be deprecated by lenny, I guess
that's one possibility. :)
Matz said ruby 1.9.1 will be out by Christmas 07 let's hope he can
meet that deadline and lenny will have ruby1.9 :D
filipe lautert
filipe { AT } icewall.org
Linux User#279798
Jabber [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
Steve Langasek wrote: On Wed, Jan 10, 2007 at 02:33:23PM -0600, Adam Majer wrote: Filipe wrote: This package is from sarge, but if someone has this installed in sarge and upgrades to etch, then it stay in the system. It provides the same functionality that logger.rb from libruby1.8 provides, and it has a file called application.rb that seems to get in the way of rails. This error can be reproduced by installing libdevel-logger-ruby1.8 from sarge (this package isn't in etch), and it can be installed without any dependencies problem. Well, it seems that the old logger was not part of the same source as ruby. I'm not sure if the conflicts should go to ruby unless the new ruby also has devel/logger.rb or application.rb. This doesn't seem to be the case though. Rather than a file conflict, this is a conflict of functionality; a target use for the proposed Breaks dpkg field. I think I'll just add the needed conflicts for Etch and remove it in the next upload after Etch is released. Seems like that may be the path of least resistance. While direct upgrades from sarge to lenny won't be supported, it would be more accurate to just leave the Conflicts: in (or change it to Breaks:) because the problem won't have disappeared, it'll just be less likely to be encountered. (Well, maybe ruby1.8 will be deprecated by lenny, I guess that's one possibility. :) I'm not sure about the Breaks. rails does not break the libdeve-logger, libdevel-logger breaks rails and libdevel-logger is not part of Debian after Sarge. Or does Breaks mean that Package: A Breaks: B Package: B then this indicates that package A is broken by B? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
On Tue, 9 Jan 2007, Steve Langasek wrote:
reassign 40 rails
found 40 1.1.6-1
retitle 40 rails should conflict with libdevel-logger-ruby1.8
severity 40 serious
thanks
On Thu, Jan 04, 2007 at 07:52:22PM -0200, Filipe wrote:
Package: libruby1.8
Version: 1.8.5-4
Severity: critical
When upgrading from sarge to etch, the package libdevel-logger-ruby1.8
isn't removed.
The functionality of this package was bundled in libruby1.8 as
/usr/lib/ruby/1.8/logger.rb. So, libruby1.8 should
replace/provide/conflict it, as it does with others packages that were
bundled in libruby1.8.
/usr/lib/ruby/1.8/logger.rb was already provided by libruby1.8 in sarge.
Why does the libruby1.8 in etch handle /usr/lib/ruby/1.8/devel/logger.rb
any
differently than libruby1.8 in sarge did?
Yes, but the functionality provided by libdevel-logger-ruby is the same
that libruby1.8 provides.
That's fine, but doesn't explain why a conflict is needed. *libruby1.8*
seems to coexist with libdevel-logger-ruby1.8 without any problems at all;
there are no conflicting file paths, and no problems I can see that result
from having two logger.rb files in the ruby include path, given that they
should be functionally equivalent.
Well, okay. But this package isn't in etch, so if there is a bug in it,
it cannot be solved.
And libruby1.8 replaces/provides/conflicts with all small libraries that
were part of it when it was split in ruby 1.6. So, I thought it was the
right place to add one more conflict, to keep the pattern and not to
spread it throught other packages.
If libruby1.8 already provides this functionality, then it should
remove the old (and wrong) one.
Should doesn't really explain why you marked this bug as critical. I'm
trying to understand what's actually broken here.
Maybe was a misunderstanding of mine about what critical is, but I
understood that it makes unrelated software on the system break, (rails).
But now that you reasign it to rails, thats ok to be serious :D
Also, if this packages remains in upgrades to etch, some rails
applications
do not work.
Why?
Because it has an file called application.rb, that gets in the way of
rails application.rb. Stupid classload issues.
Ok, but *that* is an incompatibility between rails and
libdevel-logger-ruby1.8, it has nothing to do with libruby1.8 itself. Since
this is the only real problem I see, I'm reassigning this bug report to
rails; if you can explain how the lack of a conflict breaks ruby as a whole,
we can clone this bug back to ruby1.8 as well.
AFAIK, it breaks only rails. But it is a trash that will be left behind when
people upgrade from sarge to debian - and for me, this is a bug. I don't
want a package from sarge that provides the same functionality
libruby1.8 provides in my etch machine.
RAILS people, about this bug report:
If I run my application with ./script/server, without
libdevel-logger-ruby1.8 installed, I got this on my log/development.log file:
Processing TestsController#index (for 127.0.0.1 at 2007-01-09 09:40:29) [GET]
Session ID: 1f1602ab0efe5202135a4feda77b57d4
Parameters: {action=index, controller=tests}
^[[4;36;1mTest Load (0.118763)^[[0m ^[[0;1mSELECT * FROM tests ^[[0m
Rendering layoutfalseactionlist within layouts/tests
Rendering tests/list
^[[4;35;1mTest Columns (0.063117)^[[0m ^[[0mSHOW FIELDS FROM tests^[[0m
Completed in 0.32412 (3 reqs/sec) | Rendering: 0.07891 (24%) | DB: 0.18188
(56%) | 200 OK [http://localhost/]
But if I only install libdevel-logger-ruby1.8 and restart ./script/server, I
got:
Processing Base#index (for 127.0.0.1 at 2007-01-09 09:42:33) [GET]
Session ID: 1852f423b2d0b14b5c74cc68ba4874ee
Parameters: {}
NameError (uninitialized constant ApplicationController):
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:123:in
`const_missing'
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:131:in
`const_missing'
/app/controllers/casamentos_controller.rb:1
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:140:in
`load'
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:140:in
`load'
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:56:in
`require_or_load'
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:30:in
`depend_on'
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:85:in
`require_dependency'
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:98:in
`const_missing'
.//vendor/rails/activesupport/lib/active_support/dependencies.rb:131:in
`const_missing'
generated/routing/recognition.rb:4:in `recognize_path'
.//vendor/rails/actionpack/lib/action_controller/routing.rb:511:in
`recognize!'
.//vendor/rails/railties/lib/dispatcher.rb:38:in `dispatch'
.//vendor/rails/railties/lib/webrick_server.rb:115:in `handle_dispatch'
.//vendor/rails/railties/lib/webrick_server.rb:81:in `service'
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
Filipe wrote: This package is from sarge, but if someone has this installed in sarge and upgrades to etch, then it stay in the system. It provides the same functionality that logger.rb from libruby1.8 provides, and it has a file called application.rb that seems to get in the way of rails. This error can be reproduced by installing libdevel-logger-ruby1.8 from sarge (this package isn't in etch), and it can be installed without any dependencies problem. Well, it seems that the old logger was not part of the same source as ruby. I'm not sure if the conflicts should go to ruby unless the new ruby also has devel/logger.rb or application.rb. This doesn't seem to be the case though. I think I'll just add the needed conflicts for Etch and remove it in the next upload after Etch is released. Seems like that may be the path of least resistance. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
reassign 40 rails found 40 1.1.6-1 retitle 40 rails should conflict with libdevel-logger-ruby1.8 severity 40 serious thanks On Thu, Jan 04, 2007 at 07:52:22PM -0200, Filipe wrote: Package: libruby1.8 Version: 1.8.5-4 Severity: critical When upgrading from sarge to etch, the package libdevel-logger-ruby1.8 isn't removed. The functionality of this package was bundled in libruby1.8 as /usr/lib/ruby/1.8/logger.rb. So, libruby1.8 should replace/provide/conflict it, as it does with others packages that were bundled in libruby1.8. /usr/lib/ruby/1.8/logger.rb was already provided by libruby1.8 in sarge. Why does the libruby1.8 in etch handle /usr/lib/ruby/1.8/devel/logger.rb any differently than libruby1.8 in sarge did? Yes, but the functionality provided by libdevel-logger-ruby is the same that libruby1.8 provides. That's fine, but doesn't explain why a conflict is needed. *libruby1.8* seems to coexist with libdevel-logger-ruby1.8 without any problems at all; there are no conflicting file paths, and no problems I can see that result from having two logger.rb files in the ruby include path, given that they should be functionally equivalent. If libruby1.8 already provides this functionality, then it should remove the old (and wrong) one. Should doesn't really explain why you marked this bug as critical. I'm trying to understand what's actually broken here. Also, if this packages remains in upgrades to etch, some rails applications do not work. Why? Because it has an file called application.rb, that gets in the way of rails application.rb. Stupid classload issues. Ok, but *that* is an incompatibility between rails and libdevel-logger-ruby1.8, it has nothing to do with libruby1.8 itself. Since this is the only real problem I see, I'm reassigning this bug report to rails; if you can explain how the lack of a conflict breaks ruby as a whole, we can clone this bug back to ruby1.8 as well. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
Package: libruby1.8
Version: 1.8.5-4
Severity: critical
When upgrading from sarge to etch, the package libdevel-logger-ruby1.8
isn't removed.
The functionality of this package was bundled in libruby1.8 as
/usr/lib/ruby/1.8/logger.rb. So, libruby1.8 should
replace/provide/conflict it, as it does with others packages that were
bundled in libruby1.8.
Also, if this packages remains in upgrades to etch, some rails applications
do not work.
filipe lautert
filipe { AT } icewall.org
Linux User#279798
Jabber [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
On Thu, Jan 04, 2007 at 11:40:25AM -0200, Filipe wrote: Package: libruby1.8 Version: 1.8.5-4 Severity: critical When upgrading from sarge to etch, the package libdevel-logger-ruby1.8 isn't removed. The functionality of this package was bundled in libruby1.8 as /usr/lib/ruby/1.8/logger.rb. So, libruby1.8 should replace/provide/conflict it, as it does with others packages that were bundled in libruby1.8. /usr/lib/ruby/1.8/logger.rb was already provided by libruby1.8 in sarge. Why does the libruby1.8 in etch handle /usr/lib/ruby/1.8/devel/logger.rb any differently than libruby1.8 in sarge did? Also, if this packages remains in upgrades to etch, some rails applications do not work. Why? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405555: libruby1.8 should replaces/provides/conflicts with libdevel-logger-ruby1.8
On Thu, 4 Jan 2007, Steve Langasek wrote:
On Thu, Jan 04, 2007 at 11:40:25AM -0200, Filipe wrote:
Package: libruby1.8
Version: 1.8.5-4
Severity: critical
When upgrading from sarge to etch, the package libdevel-logger-ruby1.8
isn't removed.
The functionality of this package was bundled in libruby1.8 as
/usr/lib/ruby/1.8/logger.rb. So, libruby1.8 should
replace/provide/conflict it, as it does with others packages that were
bundled in libruby1.8.
/usr/lib/ruby/1.8/logger.rb was already provided by libruby1.8 in sarge.
Why does the libruby1.8 in etch handle /usr/lib/ruby/1.8/devel/logger.rb any
differently than libruby1.8 in sarge did?
Yes, but the functionality provided by libdevel-logger-ruby is the same
that libruby1.8 provides.
If you check http://raa.ruby-lang.org/project/devel-logger/, it
says: devel-logger is bundled together with ruby distribution after ruby/1.8.
This package is for ruby-1.6.
So, it seems that this package was wrongly migrated to ruby1.8.
Then the maintainer removed the 1.8 package from etch, and in dummy package
libdevel-logger-ruby, the file /usr/share/doc/libdevel-logger-ruby/README.Debian
says:
libdevel-logger-ruby for Debian
---
Ruby Devel::Logger
It was bundled in ruby1.8 as logger.rb. This is just dummy package
so that you may remove it.
-- Fumitoshi UKAI [EMAIL PROTECTED], Fri, 12 May 2006 01:44:51 +0900
If libruby1.8 already provides this functionality, then it should
remove the old (and wrong) one.
Also, if this packages remains in upgrades to etch, some rails applications
do not work.
Why?
Because it has an file called application.rb, that gets in the way of
rails application.rb. Stupid classload issues.
filipe lautert
filipe { AT } icewall.org
Linux User#279798
Jabber [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
