I know

--link

will deny me from going back to previous PSQL versions, but luckily i'm not testing on the actual server, but on a clone of said server, with snapshots. So if it breaks, i simply revert the snapshot and try again

ah okay

smart 😄

Although i think that the normal upgrade (without

--link

) won't take that long. I'm used to using

--link

when upgrading 500G+ databases with limited diskspace. PuppetDB is a fraction of that

and if you've old reports/dead nodes you can even remove them from the DB before doing an upgrade

I just installed pgsql 16 and my puppetdb/puppetboard are doing fine as far as I can tell.

but what's your puppetdb version? 😄

puppetdb 8 works fine with it

but 6? should be tested

puppetdb-7.17.1-1.el8.noarch

Maybe I'm just overseeing something simple, but I want to always extract a zipfile, when it is renewed in the source, but somehow It just doesn't.

archive { '/tmp/file.zip':
  ensure        => present,
  source        => "${source}/file.zip",
  extract       => true,
  extract_path  => "/tmp/foo/",
  user          => $user,
}

When the files already exist in /tmp/foo, nothing happens. Even when I first make sure the zipfile changes by first using file and then archive, it doesn't work. Unless I remove the files in the extract_path folder.

file { '/tmp/file.zip':
  ensure => file,
  mode   => '0750',
  owner  => $user,
  source => "${source}/file.zip",
}
archive { '/tmp/file.zip':
  ensure        => present,
  source        => "/tmp/file.zip",
  extract       => true,
  extract_path  => "/tmp/foo/",
  user          => $user,
}

I tried adding a notify and extract_flags, but that doesn't work. Should I skip the archive and just do an exec?

We've run into an issue with the apt package provider and packages with an epoch of 0 (zero). And somewhat related to that `versioncmp()`'s inability to support it, too. First, the

versioncmp()

narrative:

# cat /tmp/test.pp
$pkg_version = '7:8.2.2+ds-225736~fakeco'

notify { 'cmp_output':
  message => versioncmp($pkg_version, '8'),
}
# puppet apply /tmp/test.pp
Notice: Compiled catalog for <http://server.example.com|server.example.com> in environment production in 0.01 seconds
Notice: /Stage[main]/Main/Notify[cmp_output]/message: current_value 'absent', should be -1 (noop)
Notice: Class[Main]: Would have triggered 'refresh' from 1 event
Notice: Stage[main]: Would have triggered 'refresh' from 1 event
Notice: Applied catalog in 0.07 seconds

Then the apt package provider:

irb(main):012:0> match, epoch, upstream_version, debian_revision = "1.10.1-223975".match(REGEX_FULL_RX)
=> #<MatchData "1.10.1-223975" 1:nil 2:"1.10.1" 3:"223975">
irb(main):013:0> match, epoch, upstream_version, debian_revision = "0:1.10.1-223975".match(REGEX_FULL_RX)
=> #<MatchData "0:1.10.1-223975" 1:"0" 2:"1.10.1" 3:"223975">

This is from the code:

def self.parse(ver)
      raise ValidationFailure, "Unable to parse '#{ver}' as a string" unless ver.is_a?(String)

      match, epoch, upstream_version, debian_revision = *ver.match(REGEX_FULL_RX)

      raise ValidationFailure, "Unable to parse '#{ver}' as a debian version identifier" unless match

      new(epoch.to_i, upstream_version, debian_revision).freeze
    end
[...]
    def eql?(other)
      other.is_a?(self.class) &&
        @epoch.eql?(other.epoch) &&
        @upstream_version.eql?(other.upstream_version) &&
        @debian_revision.eql?(other.debian_revision)
    end
    alias == eql?

Two issues, but kind of related. For the

versioncmp()

issue, I had to first process the version string with

(?:.*:)?(\d+(\.\d+)*)(?:[+~-].*)?

The package provider issue is that it keeps not seeing the installed version as the same as the one in the repo. We've resolved it temporarily by publishing the package without an epoch.

And now that I see the spam I just dropped, I wish I'd created a thread on the first post to drop that all into. 😞

I don't think it's fair to expect for versioncmp to deal with intricacies of a package version. it only deals with SemVer

you would have to split epoch and the rest in two parts and compare them separately

I wouldn't know how to answer this question

versioncmp($pkg_version, '8'),

if epoch is involved 🙂, it's ambiguous

Aye,

versioncmp()

is a very generic function and this sort of stuff is deep "inside Debian baseball". Apt provider should definitely handle it though.

Yeah. Maybe a helper function specific to apt package versioning could be envisioned, I guess. My workaround is fine. The other issue with package "flapping" is annoying, though.

time to implement

apt::pkg_versioncmp()

function which will consider epoch 🙂

(and find that puppet-agent package for Debian 12 has lower version than for Puppet 11 (which has lower version than for Puppet 10))

Was that last a kind of quip or perhaps involved in why the provider isn't doing this right?

My colleague looked at the code in Github and it looks like it hasn't changed in 5 years.

Assuming we write a fix and submit a PR, how would one operate from their own version until it was merged? Some Gemfile override somewhere?

honestly, you get the PR merged then poke the puppet folks to cut you a release, which they tend to be good about 🙂

I've had my PRs sit for awhile, too. I just would like a way to operate while waiting.

you could always just use your fork via git in r10k