On Thu, Jan 5, 2012 at 10:23 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
If pacman 3.5.4-4 can't connect to a repo that's listed in pacman.conf, it will throw a bunch of errors
error: could not open file /var/lib/pacman/sync/allanbrokeit.db: Failed to open '/var/lib/pacman/sync/allanbrokeit.db' error: could not open file /var/lib/pacman/sync/allanbrokeit.db: Failed to open '/var/lib/pacman/sync/allanbrokeit.db' error: could not open file /var/lib/pacman/sync/allanbrokeit.db: Failed to open '/var/lib/pacman/sync/allanbrokeit.db' error: could not open file /var/lib/pacman/sync/allanbrokeit.db: Failed to open '/var/lib/pacman/sync/allanbrokeit.db' error: could not open file /var/lib/pacman/sync/allanbrokeit.db: Failed to open '/var/lib/pacman/sync/allanbrokeit.db' error: could not open file /var/lib/pacman/sync/allanbrokeit.db: Failed to open '/var/lib/pacman/sync/allanbrokeit.db' ...
but will let you update and install packages from other repos. pacman 4.0.1-X errors out:
[karol@black ~]$ pacman -Syu warning: database file for 'allanbrokeit' does not exist :: Synchronizing package databases... testing is up to date community-testing is up to date core is up to date extra is up to date community is up to date error: failed retrieving file 'allanbrokeit.db' from allanmcrae.com : The requested URL returned error: 404 error: failed to update allanbrokeit (download library error) :: Starting full system upgrade... error: failed to prepare transaction (could not find database)
[karol@black ~]$ pacman -S hdparm warning: database file for 'allanbrokeit' does not exist error: failed to prepare transaction (could not find database)
hdparm is in [core]. allanbrokeit repo is already back online, so you have to test it with some nonexistent repo & db.
The error messages are clear enough and you only have to comment out the repo that e.g. went offline to "fix" pacman. This behavior may be a feature [1] but I wanted to make sure this is how it's meant to be. Yes, this was mostly an intended change.
Note that you can do an -R operation (or anything not requiring sync databases) just fine. However, once we hit any machinery that requires sync databases to be present, we require all configured ones are accounted for. This is for a few reasons: 1) dependency resolving if you have 1 out-of-date database and 4 up-to-date ones, things can get ugly or messed up. 2) integrity- if you insist on a database being signed, we'd rather not proceed with nothing. 3) replay attacks- what you don't fully see in the above situation is we also validate the signature on the database at load time; if that were to fail we'd also bail out. This is so pacman is capable of verifying the expiration time on a database signature; it makes sense to only allow database signatures to be valid for a week at a time so people know they have out-of-date repo metadata.
[1] See Allan's post https://bbs.archlinux.org/viewtopic.php?pid=1034943#p1034943