Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#39043 closed defect (duplicate)

rb-rspec @1.1.11 conflicts with rb19-rspec @1.3.0

Reported by: cooljeanius (Eric Gallager) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: kimuraw (kimura wataru)
Port: rb-rspec rb19-rspec

Description

While installing rb-rspec, it failed to activate, because rb19-rspec was already active. I tried again with -f to see which files got moved aside:

Warning: File /opt/local/bin/autospec already exists.  Moving to: /opt/local/bin/autospec.mp_1368022945.
Warning: File /opt/local/bin/spec already exists.  Moving to: /opt/local/bin/spec.mp_1368022945.

Change History (13)

comment:1 Changed 11 years ago by cooljeanius (Eric Gallager)

Actually after installing some more ruby ports, this is actually a pretty common issue for gems that have both an rb-* port and an rb19-* port. Perhaps this could be fixed in the ruby portgroup?

comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: kimuraw@… added

comment:3 Changed 11 years ago by kimuraw (kimura wataru)

now, MacPorts installs rb-|rb19- SUFFIXED commands under ${prefix}/bin such as "spec-1.8" or "spec-1.9". see changelog of r103918(2013-03-09) for more details.

I think your group/ruby-1.0.tcl might be an older version.

try this.

% sudo port selfupdate
% sudo port -nf upgrade rb-rspec rb19-rspec

expected results:

% port contents rb-rspec rb19-rspec | grep bin/
  /opt/local/bin/autospec-1.8
  /opt/local/bin/spec-1.8
  /opt/local/lib/ruby1.8/gems/1.8/bin/autospec
  /opt/local/lib/ruby1.8/gems/1.8/bin/spec
  /opt/local/lib/ruby1.8/gems/1.8/gems/rspec-1.1.11/bin/autospec
  /opt/local/lib/ruby1.8/gems/1.8/gems/rspec-1.1.11/bin/spec
  /opt/local/bin/autospec-1.9
  /opt/local/bin/spec-1.9
  /opt/local/lib/ruby1.9/gems/1.9.1/bin/autospec
  /opt/local/lib/ruby1.9/gems/1.9.1/bin/spec
  /opt/local/lib/ruby1.9/gems/1.9.1/gems/rspec-1.3.0/bin/autospec
  /opt/local/lib/ruby1.9/gems/1.9.1/gems/rspec-1.3.0/bin/spec

comment:4 Changed 11 years ago by cooljeanius (Eric Gallager)

Yeah, I saw that change, so that's why I'm confused that this is happening. Anyways, I'm on a fresh computer now, and this still happens:

gl00b05046:~ egall$ port contents rb-rspec rb19-rspec | grep bin/
  /opt/local/bin/autospec.mp_1368277179
  /opt/local/bin/spec.mp_1368277179
  /opt/local/lib/ruby/gems/1.8/bin/autospec
  /opt/local/lib/ruby/gems/1.8/bin/spec
  /opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/bin/autospec
  /opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/bin/spec
  /opt/local/bin/autospec
  /opt/local/bin/spec
  /opt/local/lib/ruby1.9/gems/1.9.1/bin/autospec
  /opt/local/lib/ruby1.9/gems/1.9.1/bin/spec
  /opt/local/lib/ruby1.9/gems/1.9.1/gems/rspec-1.3.0/bin/autospec
  /opt/local/lib/ruby1.9/gems/1.9.1/gems/rspec-1.3.0/bin/spec
gl00b05046:~ egall$ port installed rb*rspec
The following ports are currently installed:
  rb-rspec @1.1.11_0 (active)
  rb19-rspec @1.3.0_0 (active)
gl00b05046:~ egall$ port installed ruby*
The following ports are currently installed:
  ruby @1.8.7-p371_2+universal (active)
  ruby19 @1.9.3-p392_1+doc+universal (active)
  ruby_select @1.0_0 (active)
gl00b05046:~ egall$ port select ruby
Available versions for ruby:
	none (active)
	ruby18
	ruby19
Last edited 11 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:5 Changed 11 years ago by cooljeanius (Eric Gallager)

Actually it looks like they could both use updates anyways:

gl00b05046:local egall$ port -v livecheck rb*rspec
rb-rspec seems to have been updated (port version: 1.1.11, new version: 1.2.9)
rb19-rspec seems to have been updated (port version: 1.3.0, new version: 2.13.0)

comment:6 in reply to:  3 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to kimuraw@…:

now, MacPorts installs rb-|rb19- SUFFIXED commands under ${prefix}/bin such as "spec-1.8" or "spec-1.9". see changelog of r103918(2013-03-09) for more details.

I think your group/ruby-1.0.tcl might be an older version.

try this.

% sudo port selfupdate
% sudo port -nf upgrade rb-rspec rb19-rspec

expected results:

% port contents rb-rspec rb19-rspec | grep bin/
  /opt/local/bin/autospec-1.8
  /opt/local/bin/spec-1.8
  /opt/local/lib/ruby1.8/gems/1.8/bin/autospec
  /opt/local/lib/ruby1.8/gems/1.8/bin/spec
  /opt/local/lib/ruby1.8/gems/1.8/gems/rspec-1.1.11/bin/autospec
  /opt/local/lib/ruby1.8/gems/1.8/gems/rspec-1.1.11/bin/spec
  /opt/local/bin/autospec-1.9
  /opt/local/bin/spec-1.9
  /opt/local/lib/ruby1.9/gems/1.9.1/bin/autospec
  /opt/local/lib/ruby1.9/gems/1.9.1/bin/spec
  /opt/local/lib/ruby1.9/gems/1.9.1/gems/rspec-1.3.0/bin/autospec
  /opt/local/lib/ruby1.9/gems/1.9.1/gems/rspec-1.3.0/bin/spec

You can verify by downloading the packages from http://packages.macports.org/rb-rspec/ that rb-spec doesn't currently contain those files. The packages on the server are also from 2012, before r103918. Did you forget to increase the revision of rb-rspec and all other affected ports to get them to rebuild?

comment:7 Changed 11 years ago by cooljeanius (Eric Gallager)

#39248 would be a more generalized fix for this.

comment:8 Changed 11 years ago by cooljeanius (Eric Gallager)

tested, this works fine as of r106535

comment:9 Changed 11 years ago by larryv (Lawrence Velázquez)

Resolution: duplicate
Status: newclosed

Basically the same as #39248.

comment:10 Changed 11 years ago by cooljeanius (Eric Gallager)

I would've closed as "fixed" instead "duplicate" because this one was opened before the other, but whatever...

comment:11 in reply to:  10 Changed 11 years ago by larryv (Lawrence Velázquez)

Replying to egall@…:

I would've closed as "fixed" instead "duplicate" because this one was opened before the other, but whatever...

And? Chronological order is irrelevant; r106535 was committed in response to #39248, which furthermore is a more general description of the problem.

comment:12 Changed 11 years ago by cooljeanius (Eric Gallager)

Chronological order is irrelevant

Is it really?

r106535 was committed in response to #39248

Regardless of which one it was committed in response to, it still fixed this one as well while it was at it.

comment:13 in reply to:  12 Changed 11 years ago by larryv (Lawrence Velázquez)

Replying to egall@…:

Chronological order is irrelevant

Is it really?

The only thing “duplicate” means is “this ticket is about the same problem as another ticket”.

r106535 was committed in response to #39248

Regardless of which one it was committed in response to, it still fixed this one as well while it was at it.

Closing this as a duplicate of a fixed ticket provides more information than closing it as fixed. Especially since this ticket is a strict subset of the other.

Note: See TracTickets for help on using tickets.