pentoo / pentoo-historical

read-only historical backup of pentoo from googlecode
https://code.google.com/p/pentoo/
2 stars 1 forks source link

activerecord dependency not properly bounded in metasploit ebuild #195

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. install funtoo-current, update @world
2. layman -a pentoo
3. emerge metasploit
4. Try running msfconsole

What is the expected output? What do you see instead?
Error about "deprecated_mass_assignment_security.rb:17:in `attr_accessible'" or 
the like. I looked this up. It happens when using activesupport-4.x instead of 
3.x.

Manually downgrading to the active{record,support,model}:3.0 slot fixed the 
problem. Hence, I suggest adding a range to the dependency in the metasploit 
ebuild.

What version of the product are you using? On what operating system?
funtoo-current ("current" is roughly equivalent to gentoo unstable branch like 
~amd64)

Please provide any additional information below.

Below is my patch. activerecord already depends on activesupport, so I've 
elided it for maintainability. The activerecord-4 blocker is the proper way to 
prevent this incompatibility from arising, I believe. The alternative is to use 
a range or slot qualifier, as detailed at 
http://devmanual.gentoo.org/general-concepts/dependencies/ , but I'm unclear on 
which exact set of versions is appropriate (seems to be >=3.2.11, but can't be 
sure).

--- net-analyzer/metasploit/metasploit-4.6.0.ebuild     2013-11-19 
07:34:26.724101935 -0800
+++ net-analyzer/metasploit/metasploit-4.6.0.ebuild.new 2013-11-19 
07:34:31.434108843 -0800
@@ -29,8 +29,8 @@
 RDEPEND="${DEPEND}
        dev-db/postgresql-server
        dev-lang/ruby[ssl]
-       >=dev-ruby/activesupport-3.0.0
        >=dev-ruby/activerecord-3.2.11
+       !>=dev-ruby/activerecord-4
        dev-ruby/json
        >=dev-ruby/metasploit_data_models-0.6.4
        dev-ruby/msgpack

Original issue reported on code.google.com by eli...@gmail.com on 19 Nov 2013 at 3:46

GoogleCodeExporter commented 9 years ago
Oops, using a blocker is not correct. Emerge doesn't seem to try to solve its 
way around the blocker like it does with other dependencies when it comes time 
to upgrade @world. I don't understand why. Anyway, it looks like the dependency 
line will have to use either a range or slot qualifier, i.e, one of:
=dev-ruby/activerecord-3.2*
dev-ruby/activerecord:3.2

I can't see any way to select a range more narrow than a whole 
major/minor/release number at a time, so hopefully one of these maps 
appropriately to the actual dependency.

Original comment by eli...@gmail.com on 19 Nov 2013 at 4:23

GoogleCodeExporter commented 9 years ago
thanks for the report, this should fix it for you
Committed revision 5222

Original comment by sidhayn on 19 Nov 2013 at 6:30