VMiklos wrote:

On Sat, Feb 18, 2006 at 10:15:00AM +0100, Aurelien Foret wrote: i would say filter the output in trans.c, so that the fronend is allowed to choose if it asks the user or not

here is a patch for that: http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdif...;

This patch is fixing outputs at the frontend level, but IMO, that's not enough. If I look at code more closely at pacman 2.9.8 code, there are several chunks of code enclosed by the "if(!downloadonly) { ... }" statement which does not exist in the cvs code. Basically, in sync_prepare, the "checkconflict" part should not be performed. Idea: when should maybe split the code chunk in sync_prepare dealing with deps and conflicts within the "if(!FLAG_NODEPS) { ... }" block in two parts: if(!FLAG_NODEPS) { checkdeps... } if(!FLAG_NOCONFLICT) { checkconflict... } with FLAG_NOCONFLICT being a new flag, that the frontend should force when running "-Sw" in order to bypass all the conflicts checking. Thoughts? -- Aurelien

VMiklos wrote:

On Mon, Feb 20, 2006 at 08:56:40PM +0100, Aurelien Foret wrote:

...

If I look at code more closely at pacman 2.9.8 code, there are several chunks of code enclosed by the "if(!downloadonly) { ... }" statement which does not exist in the cvs code. Basically, in sync_prepare, the "checkconflict" part should not be performed.

is it really good? the typical usage of downloadonly is when you have to update a lot of packages, and you have a fast connection, then later you can upgrade the packages. in this scenario, imho it's really annoying if i download a package and later pacman tells me that i can't install the package i already downloaded

If I want to download a package somehow involved in a conflict, why pacman would prevent me to get it? It's better to let the user download too much packages (and when I say too much, I mean 1 or 2 packages in less than 5% of cases), than restrict him to get one. A user may want to download a package, possibly only to inspect it, rather than install it. And the download code from the frontend does not care if a package is elected for removal or installation: all packages from trans->packages are downloaded. IMO, checking conflicts is pointless. BTW, I applied your patch fixing outputs in src/pacman/trans.c. It looks nicer this way. Thanks.

...

Idea: when should maybe split the code chunk in sync_prepare dealing with deps and conflicts within the "if(!FLAG_NODEPS) { ... }" block in two parts:

if(!FLAG_NODEPS) { checkdeps... } if(!FLAG_NOCONFLICT) { checkconflict... }

with FLAG_NOCONFLICT being a new flag, that the frontend should force when running "-Sw" in order to bypass all the conflicts checking.

Thoughts?

or just name it "downloadonly", probably this is the only case the frontend should use it

"noconflict" is just fine: that's exactly what the feature is about. The word "download" should be banned from alpm lexical dictionary... -- Aurelien

Hi, The following items can be considered as closed: [7] remove exit calls from libalpm [10] pacman -Sw (I've added a NOCONFLICTS flag to transactions to bypass conflicts in case of a download only operation) For information, I'm still working on item [6]. I've added and committed a few more debug messages regarding conflicts handling. Some logs about file conflicts are still missing. Here is the updated TODO: [2] possible db corruption because of pmsyncpkg_t struct: the spkg field is just a pointer to data from the cache, which is likely to change during sync_commit [5] database cleanup b) do not add name and version entries in "desc" file (already available in the directory name), and also for .PKGINFO file (in makepkg)? => on hold for now [6] more debug messages in libalpm some parts of the code still remain obscure (file conflicts handling for instance) even when running pacman with "--debug=-1" [8] .lastupdate review Is the .lastupdate file really needed? Using mtime isn't enough? [9] review file conflict code See this thread: http://www.archlinux.org/pipermail/pacman-dev/2006-February/000202.html -- Aurelien