The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #2331

darwinports "install" broken

Added by asa hammond almost 7 years ago. Updated about 5 years ago.

Status:ClosedStart date:06/09/2009
Priority:HighDue date:
Assignee:Nigel Kersten% Done:

0%

Category:OSXEstimated time:1.00 hour
Target version:2.6.8
Affected Puppet version:0.25.1 Branch:
Keywords:darwinports, macports

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

looks like the darwinport provider is not able to “install” on osx leopard. ports tries “port update” instead of “port install” when first installing a package. Seems that macports Version: 1.710 has this issue.

darwinport.rb.patch Magnifier (1.51 KB) asa hammond, 06/10/2009 08:47 pm

macports.rb Magnifier (2.32 KB) asa hammond, 01/31/2010 08:50 pm


Related issues

Duplicated by Puppet - Bug #2579: Darwinport package provider broken in 0.25rc1 Duplicate 08/28/2009

History

#1 Updated by asa hammond almost 7 years ago

  • File darwinport.rb.patch added

asa – wrote:

looks like the darwinport provider is not able to “install” on osx leopard. ports tries “port update” instead of “port install” when first installing a package. Seems that macports Version: 1.710 has this issue.

oops. setup patch in wrong order. attaching corrected version.

#2 Updated by asa hammond almost 7 years ago

  • File deleted (darwinport.rb.patch)

#3 Updated by asa hammond almost 7 years ago

  • File deleted (darwinport.rb.patch)

#4 Updated by asa hammond almost 7 years ago

  • File darwinport.rb.patch added

newer patch

#5 Updated by James Turnbull almost 7 years ago

  • Category set to OSX
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Nigel Kersten

Nigel?

#6 Updated by asa hammond almost 7 years ago

  • File deleted (darwinport.rb.patch)

#7 Updated by asa hammond almost 7 years ago

  • File darwinport.rb.patchMagnifier added
  • Keywords changed from darwinport, macports to darwinports, macports

Found something else with the listing of versions, where we really want to be using ‘port list’, vs ‘port search’ as search returns all kinds of other ports which have the requested string, see the bzr package for a good example.

‘port search bzr’ pulls up a bunch of packages and the default install of puppet was trying to upgrade to the (devel) version at each run.

This patch is working for me…

#8 Updated by Nigel Kersten almost 7 years ago

I didn’t actually do this provider.

I’m happy to have a look at it later, but I have a bunch of more core Mac bugs to work on with the macauthorization provider.

I should be able to get to it within a week or two.

#9 Updated by Nigel Kersten over 6 years ago

  • Affected Puppet version changed from 0.24.8 to 0.25.0rc1

#10 Updated by John Axel Eriksson over 6 years ago

  • Priority changed from Normal to High
  • Estimated time set to 1.00
  • Affected Puppet version changed from 0.25.0rc1 to 0.25.1

This is still not fixed in puppet 0.25.1. This means basically that the darwinport provider is broken since it cannot install anything. It should be really simple to fix, I’ve looked at it myself and it seems trivial, I’m no ruby expert though unfortunately though I hope to be one…

#11 Updated by Nigel Kersten over 6 years ago

I’m looking at your patch now.

#12 Updated by Nigel Kersten over 6 years ago

So the patch looks fine, but it does raise some issues with old port versions, as this will break those…

I’m really not sure what the best way to handle this is. Should we interrogate the port version and do some comparison checks with backward compatible paths? I fully expect us to see this change in the future.

When did the name change to MacPorts happen? It wasn’t at the same time as this was it?

#13 Updated by Markus Roberts over 6 years ago

  • Target version set to 0.25.2

#14 Updated by Jesse Wolfe over 6 years ago

  • Target version changed from 0.25.2 to 0.25.3

Bumped to 0.25.3 while these questions remain unanswered.

#15 Updated by Markus Roberts over 6 years ago

  • Target version changed from 0.25.3 to 0.25.4

#16 Updated by Nigel Kersten over 6 years ago

To clarify, the reason I asked about the name change is that I’m thinking we could have a darwinport and macport provider that behave correctly for each of their versions, with appropriate restrictions in place to make sure the correct one is the default provider.

#17 Updated by asa hammond over 6 years ago

Two providers would solve things for me, trying to stay on macports, and for others who want to keep their darwinports installs working.

#18 Updated by Nigel Kersten over 6 years ago

I wonder how many people are running versions of MacPorts that are this old… still, it would be good if we could pinpoint exactly when this behaviour changed.

#19 Updated by James Turnbull over 6 years ago

  • Target version changed from 0.25.4 to 0.25.5

#20 Updated by asa hammond about 6 years ago

I made a separate provider for macports and attached it here. Works ok for me.

#21 Updated by Markus Roberts about 6 years ago

  • Status changed from Needs Decision to Accepted

#22 Updated by James Turnbull about 6 years ago

  • Target version changed from 0.25.5 to 49

#23 Updated by Sergio Gelato over 5 years ago

Nigel Kersten wrote:

I wonder how many people are running versions of MacPorts that are this old… still, it would be good if we could pinpoint exactly when this behaviour changed.

The MacPorts ChangeLog mentions the following:

------------------------------------------------------------------------
r46052 | jmr@macports.org | 2009-01-28 02:32:11 +0100 (Wed, 28 Jan 2009) | 2 lines
Error out when asked to upgrade a port that is not installed, e.g. the infamous "port upgrade all"
------------------------------------------------------------------------

This first appeared in the 1.7.1 release.

A more interesting question, to which I don’t have an answer, is how far back one has to go to find a release where “port install” cannot be used. Do we even know that that was the reason for trying to use “port upgrade” always (as opposed to the well-known programmer’s virtue called laziness)?

#24 Updated by Nigel Kersten over 5 years ago

I’m assuming laziness :)

Thanks for finding that Sergio.

I think we should just pick a next major release to deprecate the ‘darwinports’ installer and use ‘macports’ instead.

#25 Updated by Markus Roberts over 5 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Assignee deleted (Nigel Kersten)
  • Target version changed from 49 to 2.7.x

#26 Updated by Brian Gupta about 5 years ago

Please note, the macports.rb attached to this bug report is not working for ports that haven’t been installed and is using the port upgrade subcommand. (Update: Further testing revealed that “ensure => present” works, but “ensure => latest” doesn’t.

debug: Puppet::Type::Package::ProviderMacports: Executing ‘/opt/local/bin/port upgrade watch’ err: /Stage[main]//Node[default]/Package[watch]/ensure: change from absent to latest failed: Could not update: Execution of ‘/opt/local/bin/port upgrade watch’ returned 1: Error: watch is not installed To report a bug, see http://guide.macports.org/#project.tickets at /Users/bgupta/git/mac-puppet/mac-ports.pp:46

Here is the code that I used to call it:

package { “watch”:

  ensure => latest,
  provider => macports,

}

Tested with puppet v2.6.4

#27 Updated by Nigel Kersten about 5 years ago

  • Status changed from In Topic Branch Pending Review to Code Insufficient

Thanks for testing Brian.

#28 Updated by Nigel Kersten about 5 years ago

  • Assignee set to Nigel Kersten
  • Target version changed from 2.7.x to 2.6.x

I’m basically redoing most of this provider right now. We’ve had several issues that have been confused together.

Given how broken we are on 2.6.x right now, I’m going to target this at 2.6.x and Statler. The backwards compatibility isn’t a significant issue any more.

#29 Updated by Nigel Kersten about 5 years ago

I’m still working on the tests, as this provider didn’t have any at all.

If anyone feels like following along however, I’ve got the core functionality working here: https://github.com/nigelkersten/puppet/blob/WIP/tickets/2.6.x/2331/lib/puppet/provider/package/macports.rb

Note that I’ve added version support so you can do:

package { "rxvt-unicode":
  ensure    => "9.0.0",
  provider => "macports",
}

It turned out easy to add it while I was fixing the “ensure => latest” situation. This provider should be significantly faster than the previous ones, as we’re not using the slow commands.

#30 Updated by Nigel Kersten about 5 years ago

  • Status changed from Code Insufficient to Merged - Pending Release

sent to dev-list

https://github.com/nigelkersten/puppet/tree/tickets/2.6.x/2331-macports-provider

#31 Updated by Nigel Kersten about 5 years ago

  • Status changed from Merged - Pending Release to Closed

Pushed to 2.6.next. This will be in today’s RC.

#32 Updated by James Turnbull about 5 years ago

  • Target version changed from 2.6.x to 2.6.8

Also available in: Atom PDF