suggestion: Host fly-off between pkgin and nih and subsequent official integration

[John Marino <netbsd%marino.st@localhost>]

I've been wondering why the pkgsrc project hasn't held a "fly-off" 
between pkgin and nih in order to select an official package manager, 
and then integrate this directly into the mk/* framework such that the 
very first package built is this official package manager.

This is what the FreeBSD Ports Collection has done with pkgng and I 
think it was quite an improvement for ports.  For pkgsrc, it seems like 
having an integrated binary package manager would "fix" the problems 
seen with the "experimental" "make replace" and untrustworthy 
pkg_rolling-replace.  Now, not having used either pkgin or nim, I'm only 
assuming one or both of them are similar to pkgng where they have their 
own database and internally store package metadata which is why it needs 
to be built first.  Hopefully my ignorance of these tools isn't 
invalidating my question.

So basically I'm wondering:
1) Would having an integrated binary package manager solve some of 
pkgsrc's warts and generally improve its usability?

2) If the answer is a resounding "yes", why hasn't the process to select 
and integrate one started?


I don't have an opinion which manager is better, and I don't know if 
there's a third candidate.  I just think of the old American football 
axiom, "If you have two quarterbacks, you really have none."  In the 
same vein, pkgsrc should evaluate these candidate binary package 
managers and integrate one of them rather than stick with "choice is 
good", especially when the default choice is "no manager.

What do others think?

John