From owner-freebsd-ports@FreeBSD.ORG Tue May 14 01:53:10 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D343A11 for ; Tue, 14 May 2013 01:53:10 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0E97E7 for ; Tue, 14 May 2013 01:53:08 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 99EBD3B2A2 for ; Mon, 13 May 2013 18:53:04 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-ports@freebsd.org Subject: Re: WANTED: Tool to verify installed package/port consistancy Date: Mon, 13 May 2013 18:53:04 -0700 Message-ID: <73516.1368496384@server1.tristatelogic.com> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 01:53:10 -0000 Well, I have looked a bit more at some of the files that posted about just a short while ago. It turns out that pretty much all of the remaining anomolies (i.e. MD5 mismatches) in package-related or port- related files on my system can be attributed to either (a) some person or else (b) some thing (e.g. some other package or port install script) coming along _after_ a given port/package has been initially installed and then diddling one or more of the relevant files. It is easy to understand how or why this might happen, e.g. in cases involving various configuration files that may have meaning to more than one port or package. So anyway, I revised my pkg_sanity script so that it will compare the date/time stamps of files against the date/time stamps of the corresponding +CONTENTS files (and report anomolies found) before it even bothers trying to check the MD5 checksums. Obviously, if some given file has been diddled since the date/time when its MD5 checksum was originally computed for inclusion in the relevant +CONTENTS file, then it is almost an absolute certainty that it's new/current MD5 checksum is _not_ going to match its old one, as contained in the relevant +CONTENTS file. Running my revised version of the script yields this output: pkg_sanity: gettext-0.18.1.1: Newer than +CONTENTS file: /usr/local/lib/charset.alias pkg_sanity: linux_base-f10-10_5: Newer than +CONTENTS file: /compat/linux/etc/ld.so.cache pkg_sanity: linux_base-f10-10_5: Newer than +CONTENTS file: /compat/linux/var/cache/ldconfig/aux-cache pkg_sanity: p5-XML-SAX-0.99: /usr/local/lib/perl5/site_perl/5.14.2/XML/SAX/ParserDetails.ini: File failed MD5 checksum pkg_sanity: p5-XML-SAX-0.99: /usr/local/lib/perl5/site_perl/5.14.2/XML/SAX/ParserDetails.ini: 15bfbb02aa79670b148f21dfbac64843 versus cf8c5cb8a7b6cf7a8db7c53f1ba27148 (Oh! And by the way, this date/time stamp pre-check is one that "pkg_info -g" _should_ really be doing also, but isn't. I'll be filing a PR on that.) So it is clear that, sometime after install installation, somebody or some thing came along and diddled the charset.alias, ld.so.cache, and aux-cache files, and that thus, it is perfectly understandable that these files no longer match their original install-time MD5 checksums. These cases are therefore probably not worth worrying about. (I don't ever remember having edited any of these three files, so it must have been some other script doing it, as a side-effect of something else I had done since I installed the relevant ports.) This leaves me with one and only one anomoly, i.e. the ParserDetails.ini file. But even in that case I feel quite sure that somebody or something has intentionally diddled it, some time since it was originally installed, but whoever or whatever that is, they must have foolishly and mistakenly gone out of their way to preserve the original modification date/time stamp for that file. If I can ever figure out who or what did that, I shall chastize them appropriately with the nearest available instrument of torture. Hummm... Here's a hint. My current ParserDetails.ini file is shown below. On a different FreeBSD 9.1 system that I have here, this same file is present also, but is shorter (9 lines rather than 15) and contains only the first two sections, rather than four, as seen here. ============================================================================= [XML::SAX::PurePerl] http://xml.org/sax/features/namespaces = 1 [XML::SAX::Expat] http://xml.org/sax/features/namespaces = 1 http://xml.org/sax/features/external-general-entities = 1 http://xml.org/sax/features/external-parameter-entities = 1 [XML::LibXML::SAX::Parser] http://xml.org/sax/features/namespaces = 1 [XML::LibXML::SAX] http://xml.org/sax/features/namespaces = 1 =============================================================================