Feature #2382

package provider ports: portupgrade does not work

Added by Ryan Hutchison about 1 year ago. Updated 4 months ago.

Status:Code Insufficient Start:06/30/2009
Priority:Normal Due date:
Assignee:Ryan Hutchison % Done:

0%
Category:package
Target version:Statler
Affected version:0.24.8 Branch:
Keywords:
Votes: 2

Description

In puppet/provider/package/ports.rb the command passes argument -N which prevents installed ports from being upgraded.

  • Modified type ‘packages.rb’.
    • latest now calls install when port is absent and update when port exists, but is not the latest version.
  • Modified package provider ‘ports.rb’.
    • update now runs portupgrade with -M BATCH=yes instead of calling install.
    • install runs as normal.

Patch:

--- puppet/provider/package/ports.rb    2009-07-01 14:22:00.000000000 -0400
+++ puppet-patched/provider/package/ports.rb    2009-07-01 14:25:45.000000000 -0400
@@ -91,7 +91,13 @@ Puppet::Type.type(:package).provide :por
     end

     def update
-        install()
+        # -M: yes, we're a batch, so don't ask any questions
+        cmd = %w{-M BATCH=yes} << @resource[:name]
+
+        output = portupgrade(*cmd)
+        if output =~ /\*\* No such /
+            raise Puppet::ExecutionFailure, "Could not find package %s" % @resource[:name]
+        end
     end
 end

--- puppet/type/package.rb      2009-07-01 14:22:01.000000000 -0400
+++ puppet-patched/type/package.rb      2009-07-01 14:25:22.000000000 -0400
@@ -68,15 +68,20 @@ module Puppet
                 # in the "install" method.  So, check the current state now,
                 # to compare against later.
                 current = self.retrieve
-                begin
-                    provider.update
-                rescue => detail
-                    self.fail "Could not update: %s" % detail
-                end

                 if current == :absent
+                    begin
+                        provider.install
+                    rescue => detail
+                        self.fail "Could not install: %s" % detail
+                    end
                     :package_installed
                 else
+                    begin
+                        provider.update
+                    rescue => detail
+                        self.fail "Could not update: %s" % detail
+                    end
                     :package_changed
                 end
             end
>

History

#1
Updated by Luke Kanies about 1 year ago

  • Status changed from Unreviewed to Needs design decision

I can definitely see the reason for the change to the port provider, but this is a potentially large change in behaviour for the package type. Apparently every other package provider that supports upgrading will install a missing app or upgrade an existing app; will portupgrade not do this?

I’m concerned that making this change would require that we modify many other providers, also. At the least, have you tested this on other platforms?

#2
Updated by Ryan Hutchison about 1 year ago

Luke Kanies wrote:

I can definitely see the reason for the change to the port provider, but this is a potentially large change in behaviour for the package type. Apparently every other package provider that supports upgrading will install a missing app or upgrade an existing app; will portupgrade not do this?

I’m concerned that making this change would require that we modify many other providers, also. At the least, have you tested this on other platforms?

I understand that it may have adverse affects on other package providers. I have not been able to test it on platforms other than FreeBSD. Looking at most of the package providers it looked like they either didn’t support latest OR the provider.update ended up calling the install.

In the case of freebsd, you can install through portupgrade with the -N argument; however, when the package is already installed, when passing the -N argument it fails, saying the package is already installed. The -N argument is meant to install a new package updating the dependencies.

I can take some time to go through other package providers to include in the patch, but I don’t have a way of testing them.

Ryan Hutchison

#3
Updated by Luke Kanies about 1 year ago

  • Assignee set to Ryan Hutchison

At this point I’m comfortable accepting the patch to portupgrade, but not to the package type. We can look at that patch for the next release, but I think we’re too late in the cycle to apply it in this release.

#4
Updated by Ryan Hutchison about 1 year ago

Luke Kanies wrote:

At this point I’m comfortable accepting the patch to portupgrade, but not to the package type. We can look at that patch for the next release, but I think we’re too late in the cycle to apply it in this release.

Thanks for taking the time to consider this. If you quickly glance at the package type patch, you will notice that it fixes a very critical part of the logic.

Previously it would make a call to ‘provider.update’ regardless if the package existed or not. I simply made it more logical (if the package is absent – install it .. otherwise – update it.)

#5
Updated by Luke Kanies about 1 year ago

  • Status changed from Needs design decision to Code Insufficient
  • Target version set to 2.6.0

Before this can be merged, some more work needs to be done to make sure the other package providers still work as expected.

#6
Updated by James Turnbull 7 months ago

  • Target version changed from 2.6.0 to Statler

Also available in: Atom PDF