package repo sanity checking

["Jeremy C. Reed" <reed%reedmedia.net@localhost>]

Please see:

http://ftp.netbsd.org/pub/NetBSD/misc/reed/pkgsrc-package-sanity/

missing-or-old-pkg_summary.txt
 lists some missing pkg_summary files or pkg_summary files that are 
 probably too old

missing-important-packages.txt
 lists some NetBSD packages that maybe should be there; initially based 
 on doc/STATUS (which is very out of date).  (I chose only NetBSD since 
 many missing and I think other repos may not be official or maintained. 
 I think the maintained repos for other operating systems are hosted 
 elsewhere.)

The other files show the removals or additions of packages found in few 
old pkg_summary files. (I need to remove the second pkg_summary 
differences if is redundant.)

This will need some tuning. But hopefully it is useful.

I also noticed the repo has multiple versions of same packages available 
so even the pkg_summary files reflect this. I think this caused by 
critical fixed packages being uploaded but old ones not removed yet. I 
didn't automate this check since we already have problem of binary 
packages with same base names (apache-1 versus apache-2 etc). From a 
quick look I couldn't find any email threads about it. As a workaround, 
pkgin may look at PKGPATH and make the user choose. An example of 
duplicates is:
/ftp/pub/pkgsrc/packages/NetBSD/i386/5.0.2_2012Q1/All/typo3-4.5.14.tgz
/ftp/pub/pkgsrc/packages/NetBSD/i386/5.0.2_2012Q1/All/typo3-4.5.15.tgz
/ftp/pub/pkgsrc/packages/NetBSD/i386/5.0.2_2012Q1/All/typo3-4.6.7.tgz
/ftp/pub/pkgsrc/packages/NetBSD/i386/5.0.2_2012Q1/All/typo3-4.6.8.tgz

I also plan to check if some important opsys/arch/version repo is 
missing and check if some packages are too old.

These are not comprehensive tests, but simple and better than nothing.

After some minor adjustments, I will share them so others can use them 
also.

(By the way, the functionality provided by pkg_summary-utils and others 
are much better.)

Please note that my goal is not to cause more work for others, but to 
make it so the experience of using bianry packages for us and our users 
is great.

(We have many users that simply create and maintain their own packages 
and maybe distribute to their personal systems I think simply because 
they have bad luck with ours.)