after pkgng update, daily run still using pkg_info

Gary Aitken vagabond at
Mon Sep 30 21:17:33 UTC 2013

> On 09/30/13 07:15, Mathew Seaman wrote:
>>>> On 09/28/13 10:52, Gary Aitken wrote:
>>>> After switching to pkgng, I
>>>> noticed that my daily run output constantly complains about the
>>>> installed packages being corrupt, e.g.: "pkg_info: the package
>>>> info for package 'asciidoc-8.6.8_1' is corrupt"
>>>> The problem is with etc/periodic/daily/490.status-pkg-changes 
>>>> which is still using "pkg_info" instead of "pkg info"
>>>> Was this script supposed to be automatically updated as part of
>>>> the conversion?  What's the "right" way to upgrade this on a 9.1
>>>> release system?  Or should I just edit the script by hand and be
>>>> done with it?
>>> On 09/28/13 13:57, Mark Felder wrote: Run pkg_info. If there is
>>> anything listed you have not fully converted to pkgng and have some
>>> old broken/corrupt packages. You'll want to clean this up.
>> What does "clean this up" mean, and how does one go about it, given
>> the system is converted to using pkgng?  There is no
>> /var/db/pkg/pkgdb.db
>> Some of the packages reported as corrupt were installed *after* the 
>> conversion to pkgng, so why is pkg_info even noticing them? "pkg
>> info" reports 705 packages installed, and installs and re-installs 
>> using portmaster seem to be working.  "pkg_info" reports 14 "good" 
>> packages and 658 "corrupt" packages.  If pkg_info is picking up
>> packages installed after the conversion, why doesn't the sum of good
>> and corrupt packages equal the number pkg reports?
>> It was my understanding that after switching to pkgng, the pkg_* cmds
>> should no longer be used.  If that's the case, shouldn't the daily
>> script have been modified by the upgrade process?

> Yes, you're correct that the pkg_info command should no longer be used
> after pkgng-ifying your system.  Not because it's harmful or lead to any
> sort of breakage but simply because it won't return any meaningful
> information.
> Ideally, there shouldn't really be any of the old style package metadata
> left in /var/db/pkg after running pkg2ng but the conversion process may
> occasionaly stumble over the odd port or two.  (In which case force the
> port in question to re-install.  If you're using a package repository,
> that's 'pkg install -f pkgname' -- otherwise, just
> use the normal portmaster / portupgrade command you'ld have used pre-pkgng.)

I was a bit confused; the ones that need to be reinstalled are the
ones which pkg_info does *not* complain about.
So now the daily/490.status-pkg-changes script will complain about all
of them :-)  Consistency is good.

> If you are a portmaster user be aware that it does store various bits to
> do with managing distfiles in /var/db/pkg/pkgname-ver/ subdirectories.
> These shouldn't be confused with old style pkg_install metadata -- the
> distinguishing feature is if they contain a +CONTENTS file.
> As to why pkg2ng doesn't disable pkg_install related periodic jobs --
> pretty much because no one has implemented that. pkg comes with it's own
> set of periodic job scripts which should give you the equivalent set of
> reports via the pkg local database, so all we'd need to do is turn off
> any old pkg_install script and turn on the pkg equivalent.
> I've just created a new issue on github for that:
> Patches -- or even better, pull requests -- are welcome.

Thanks for the clarification.
Bit of a delay responding because something's screwed up with my mail service.

It's been a while since I converted, so I'm fuzzy on what pkg2ng actually did.
  $ which pkg
  $ pkg info pkg
  $ pkg which /usr/sbin/pkg
  /usr/sbin/pkg was not found in the database

I was trying to find the set of pkg's own periodic job scripts but I don't
see them, and I'm not really sure what to look for.  I tried grepping for
similarly numbered "490.status" and similarly named "status-pkg-changes" 
and came up empty, although I see the file in 
the distfile.


1. Is there some reason "pkg which" doesn't find itself?
2. Where is pkg supposed to install its "own set of periodic job scripts"
   and what do the names look like?
3. After reinstalling the ports reported by pkg_info as ok, 
   one of them,
   reinstalls fine but when done 
   still contains "old format" files:
     -rw-r--r--  1 root  wheel     45 Aug 26 22:43 +COMMENT
     -rw-r--r--  1 root  wheel   3609 Aug 26 22:43 +CONTENTS
     -rw-r--r--  1 root  wheel    178 Aug 26 22:43 +DESC
     -rw-r--r--  1 root  wheel  17553 Aug 26 22:43 +MTREE_DIRS
     -rw-r--r--  1 root  wheel    137 Sep 30 13:54 distfiles

Is it safe to simply delete the first four?

Wasn't sure whether to file a bug on this or not, so I haven't.


More information about the freebsd-questions mailing list