Hello,
I've closed items: [3] code synchro with pacman 2.9.8 [5a] db_write: database entries cleanup [11] _alpm prefix to private library functions On-going items: [7] (vmiklos) [8] (aurelien) the .lastupdate code was moved from the library to the frontend.
FYI, I'm currently working on item [6]
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"
[7] remove exit() calls from libalpm the library should never call exit() but always return an error code to the frontend (for instance, drop MALLOC macro)
[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
[10] pacman -Sw Outputs are wrong compared to pacman 2.9 Do not use log callbacks when the -w is used? or filter all outputs in trans.c depending on the downloadonly flag?
=> it should be done as the last step before a first release to avoid introducing too much changes to the CVS code at once.
On Sat, Feb 18, 2006 at 10:15:00AM +0100, Aurelien Foret aurelien@archlinux.org wrote:
[10] pacman -Sw Outputs are wrong compared to pacman 2.9 Do not use log callbacks when the -w is used? or filter all outputs in trans.c depending on the downloadonly flag?
heh, it seems i always take the last item ;)
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...;
=> it should be done as the last step before a first release to avoid introducing too much changes to the CVS code at once.
this comment was about the alpm symbol item, imho it could be removed :)
udv / greetings, VMiklos
VMiklos wrote:
On Sat, Feb 18, 2006 at 10:15:00AM +0100, Aurelien Foret aurelien@archlinux.org 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?
On Mon, Feb 20, 2006 at 08:56:40PM +0100, Aurelien Foret aurelien@archlinux.org 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
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
udv / greetings, VMiklos
VMiklos wrote:
On Mon, Feb 20, 2006 at 08:56:40PM +0100, Aurelien Foret aurelien@archlinux.org 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...
On Wed, Feb 22, 2006 at 10:16:10PM +0100, Aurelien Foret aurelien@archlinux.org wrote:
The word "download" should be banned from alpm lexical dictionary...
:) ok
udv / greetings, VMiklos
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
pacman-dev@lists.archlinux.org