On Fri, Nov 25, 2011 at 04:17:12PM +0100, Nagy Gabor wrote:

...

Scratches my own itch from FS#25667

Signed-off-by: Dave Reisner --- lib/libalpm/sync.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index 3817ec8..534499a 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -1160,7 +1160,7 @@ int _alpm_sync_commit(alpm_handle_t *handle, alpm_list_t **data) trans->state = STATE_COMMITING;

/* fileconflict check */ - if(!(trans->flags & ALPM_TRANS_FLAG_FORCE)) { + if(!(trans->flags & (ALPM_TRANS_FLAG_FORCE|ALPM_TRANS_FLAG_DBONLY))) { EVENT(handle, ALPM_EVENT_FILECONFLICTS_START, NULL, NULL);

_alpm_log(handle, ALPM_LOG_DEBUG, "looking for file conflicts\n");

This is good, if you want to install a dbonly package to own "orphan" files. This is not good, if an installed package already owns the conflicting file. Then it can happen that both foo and bar packages will contain the same file, and when you remove one of those packages, the other one will become corrupt. Btw, I don't know if this matters, this whole --dbonly stuff is quite hackish.

NG

Well, ideally, on -S --dbonly if there's a file conflict, the packages will also have a conflicts= (which will still be honored). Yes, this is all extremely hackish and shouldn't be used. Never the less, if you're performing an operation on the DB only, it really should be on the DB only. d