Issue #13501 has been updated by John Sellens.
I just ran into this as well, and thought I could provide more information. I installed a perl module by hand (rt-extension-repeatticket-master though I suspect it is a general problem), via the standard "perl Makefile.PL; make; make install" sequence. I ended up with a bsdpan package in /var/db/pkg/bsdpan-RT-Extension-RepeatTicket-0.04. The +CONTENTS file in that directory did not have an ORIGIN comment e.g. @comment ORIGIN:directory/packagename pkgdb -F complained: ---> Checking the package registry database [Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 379 packages found (-0 +1) . done] Missing origin: bsdpan-RT-Extension-RepeatTicket-0.04 -> Ignored. (the package is held; specify -f to force) My guess is that the puppet package library for freebsd is not happy if there is no ORIGIN comment. I added a fake ORIGIN line: @comment ORIGIN:bloop/blap and puppet ran fine. I'm not familiar enough with the code to know for sure, but I suspect puppet is generating a list of all installed packages using "pkg_info -aoQ" and gets a line with no ORIGIN e.g. % pkg_info "-aoQ" | grep bsdp bsdpan-RT-Extension-RepeatTicket-0.04: and is not happy with that. Would it be reasonable to change provider/package/freebsd.rb to handle an empty origin? My ruby skillz are pretty much non-existent so I won't attempt to suggest how to do that. This is with puppet-2.7.23 installed from ports on freebsd 9.0 but I suspect it applies fairly generally. Hope this helps - thanks! John ---------------------------------------- Feature #13501: Better error message for err: Could not prefetch package provider 'freebsd': No resource and no name in property hash in freebsd instance https://projects.puppetlabs.com/issues/13501#change-97255 * Author: Werner Bahlke * Status: Investigating * Priority: Normal * Assignee: Patrick Carlisle * Category: * Target version: * Affected Puppet version: * Keywords: error message, freebsd provider, freebsd * Branch: ---------------------------------------- This error has to do with installing the mail/p5-Mail-SpamAssassin package and how the new package is constructed. When we tried another test and installed a random package (found in the ports tree) manually and ran the agent again, we had no problem completing successfully, even though an unknown package was installed. The SA rule package is not "real" in the sense that it comes from the ports tree and has an entry in the INDEX file that Puppet uses. The command that Puppet uses to enumerate packages is missing a piece of information (the port's "origin"), and that causes the error that we've seen. Any other package installed from the ports tree has an origin, and Puppet doesn't have a problem, even if it didn't install it. We also found that we can prevent the sa-update cron script from registering the package after it's installed. This will allow the SA rules to be updated periodically, but it will also avoid the Puppet error. At the very least, we'd love to see a better error message from Puppet, perhaps including the package name causing the failure. That would have tipped us off sooner. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
