Re: pkgng default schedule... registering a few reasons for rethinking the final implementation...

On 08/23/2012 12:26, Jeffrey Bouquet wrote:
> I am following with dread the planned implementation of the deprecation of /var/db/pkg as a package registry... I use each /var/db/pkg directory as a database into the port installation/status, using sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix stuff.  For instance, an upgrade py26 > py27. 
> cd /var/db/pkg
> ls -lac | grep py26
> ls -lac | grep python
> as the more simple example. 
> ....
> With due respect to its developers and the persons who agree that
> the package tools could be upgraded, the mandatory 
> usage of a front-end database to a file directory one
> is here viewd as mutt-only-mbox, registry-and-bsod rather
> than /etc/local/rc files, deprecation of sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade the ports that are registered;
> ...
> I see concurrently too few tests on lower-end p2, p3 as to whether
> pkg can run with lesser memory machines (routers...) (pfsense)
> ...
> I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd,
> pfsense..) due to less-reliability, more-possibility of bugs..
>

This is of some concern to me as well. A number of our utilities /
scripts rely on checking /var/db/pkg as a means to test if a particular
package is installed. This is often much faster than running the pkg_*
commands, especially when we may be checking thousands of packages in a
single run. It will be some work to adjust our utilities to using the
various "pkg" commands now, but it can be done. What worries me is
performance. If this is significantly slower, it may cause some issues
on our end.

-- 
Kris Moore
PC-BSD Software
iXsystems