SHOW STOPPER: How can I find out which package installs a particular file?



  • The subject says it all. I need to figure out how a certain file ends up in my system, because it ends up corrupting the setup.

    I've been reinstalling pfSense from scratch probably a dozen times by now, because after minor changes, configuration reloads and/or system updates (new snapshot upgrade), I sooner or later always end up with the same file corrupted and a system that is spun out of control.

    I need to find the culprit, or else I can't use it.


  • Rebel Alliance Developer Netgate

    Test with one package at a time until you find the culprit.

    (Or do a binary search, test with half your packages on and half off, and then keep switching and reducing by half until you narrow it down)

    Or install them one by one and watch that file before and after each package.



  • @jimp:

    Test with one package at a time until you find the culprit.

    (Or do a binary search, test with half your packages on and half off, and then keep switching and reducing by half until you narrow it down)

    Or install them one by one and watch that file before and after each package.

    I'll have to try this, but I was hoping there would be some way to search a package manifest or something like that.
    The reason is, just installing the package is not enough to corrupt the file, otherwise it would be instant. It's just configuration restores (which then trigger a package refresh), or some system upgrade, that eventually trigger the problem.
    So it seems like multiple packages may install it, and it has to do in which sequence things get installed.
    Curiously enough, I got my configuration files by installing packages one-by-one, but the installation per se didn't cause the problem.
    That's why it's such a PITA to figure out what's going on.

    I would have to install each package, save the config, restore the config, wait for a new snapshot, update, restore the config again. If that sequence doesn't cause a problem, then the next package. That would take weeks.


  • Rebel Alliance Developer Netgate

    There isn't really an easy way to definitively check it like that.

    Really that file (libiconv.so.3 from your posts in other threads) should probably be on the base system I thought. It's required by quite a few things as listed on one of the package builders (not an exact list, but close…)

    
    $ grep libiconv.so.3 /var/db/pkg/*/+CONTENTS
    /var/db/pkg/libiconv-1.13.1_1/+CONTENTS:lib/libiconv.so.3
    $ cat /var/db/pkg/libiconv-*/+REQUIRED_BY
    bison-2.4.3,1
    cairo-1.10.0_3,1
    cdrtools-3.00_1
    dnsmasq-2.55,1
    elinks-0.11.7_1
    fusefs-libs-2.7.4
    gamin-0.1.10_4
    gettext-0.18.1.1
    gio-fam-backend-2.26.1
    git-1.7.4.1
    glib-2.26.1_1
    gmake-3.81_4
    help2man-1.38.4
    intltool-0.41.1
    libgcrypt-1.4.6
    libgpg-error-1.10
    libidn-1.16
    libxml2-2.7.8_1
    libxslt-1.1.26_2
    p5-Locale-gettext-1.05_3
    pecl-APC-3.1.6
    pecl-radius-1.2.5
    pecl-uploadprogress-1.0.1
    php-suhosin-0.9.32.1
    php-xdebug-2.1.0
    php52-5.2.17
    php52-bcmath-5.2.17
    php52-bz2-5.2.17
    php52-ctype-5.2.17
    php52-curl-5.2.17
    php52-dom-5.2.17
    php52-gettext-5.2.17
    php52-json-5.2.17
    php52-ldap-5.2.17
    php52-mbstring-5.2.17
    php52-mhash-5.2.17
    php52-mysql-5.2.17
    php52-openssl-5.2.17
    php52-pcntl-5.2.17
    php52-pcre-5.2.17
    php52-pdo-5.2.17
    php52-pdo_sqlite-5.2.17
    php52-posix-5.2.17
    php52-readline-5.2.17
    php52-session-5.2.17
    php52-shmop-5.2.17
    php52-simplexml-5.2.17
    php52-sockets-5.2.17
    php52-spl-5.2.17
    php52-sqlite-5.2.17
    php52-sysvmsg-5.2.17
    php52-sysvsem-5.2.17
    php52-sysvshm-5.2.17
    php52-tokenizer-5.2.17
    php52-xml-5.2.17
    php52-xmlreader-5.2.17
    php52-xmlwriter-5.2.17
    php52-zlib-5.2.17
    wol-0.7.1_2
    php52-5.2.14_1
    php52-bcmath-5.2.14_1
    php52-bz2-5.2.14_1
    php52-ctype-5.2.14_1
    php52-curl-5.2.14_1
    php52-gettext-5.2.14_1
    php52-ldap-5.2.14_1
    php52-mbstring-5.2.14_1
    php52-mhash-5.2.14_1
    php52-mysql-5.2.14_1
    php52-openssl-5.2.14_1
    php52-pcntl-5.2.14_1
    php52-pcre-5.2.14_1
    php52-posix-5.2.14_1
    php52-pdo-5.2.14_1
    php52-pdo_sqlite-5.2.14_1
    pfSense-pfSense-
    php52-readline-5.2.14_1
    php52-session-5.2.14_1
    php52-simplexml-5.2.14_1
    php52-sockets-5.2.14_1
    php52-shmop-5.2.14_1
    php52-sysvmsg-5.2.14_1
    php52-sysvsem-5.2.14_1
    php52-sysvshm-5.2.14_1
    php52-spl-5.2.14_1
    php52-sqlite-5.2.14_1
    php52-tokenizer-5.2.14_1
    php52-xml-5.2.14_1
    php52-zlib-5.2.14_1
    php52-dom-5.2.14_1
    php52-xmlreader-5.2.14_1
    php52-xmlwriter-5.2.14_1
    zmq-0.0.1
    php-xdebug-2.0.4
    php-suhosin-0.9.27
    pecl-uploadprogress-0.9.1
    php52-json-5.2.14_1
    bsdinstaller-2.0.2011.0307
    


  • @jimp:

    There isn't really an easy way to definitively check it like that.

    Really that file (libiconv.so.3 from your posts in other threads) should probably be on the base system I thought. It's required by quite a few things as listed on one of the package builders (not an exact list, but close…)

    Yes, that's why it corrupts the system and requires a new install. So my current theory is that some package under some circumstances replaces the system installed version, and after that all hell breaks lose.

    When installing the packages individually it seems that the dependencies are satisfied in the proper sequence, and the version that comes with the base system seems to remain unmolested. But during re-install or restore of a configuration somehow sooner or later things get wonky…


Log in to reply