[pacman-dev] [PATCH] -Qu rework
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working This is a big behavior change (iirc it restores the old behavior). Opinions? ------------------------------------------------------ SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu This message was sent using IMP: http://horde.org/imp/
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
This is a big behavior change (iirc it restores the old behavior). Opinions?
This is fine for me. But that means we consider bug 7884 as invalid, which was opened by Dan. So as I said in the last comment of that bug, we have to wait for his input :)
On Fri, Oct 24, 2008 at 12:53 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
This is a big behavior change (iirc it restores the old behavior). Opinions?
This is fine for me. But that means we consider bug 7884 as invalid, which was opened by Dan. So as I said in the last comment of that bug, we have to wait for his input :)
Damn, this is a huge code cleanup. I like it. I've pulled it into my working branch (the latest version). One thing I noticed and/or thought of- should we make the return status of this command different depending on whether there are upgrades available? That would make this super-easy to wrap in some sort of "up2date" script or something rather than having to parse the output. -Dan
On Fri, Oct 24, 2008 at 12:53 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
This is a big behavior change (iirc it restores the old behavior). Opinions?
This is fine for me. But that means we consider bug 7884 as invalid, which was opened by Dan. So as I said in the last comment of that bug, we have to wait for his input :)
Damn, this is a huge code cleanup. I like it. I've pulled it into my working branch (the latest version).
One thing I noticed and/or thought of- should we make the return status of this command different depending on whether there are upgrades available? That would make this super-easy to wrap in some sort of "up2date" script or something rather than having to parse the output.
This is a good idea. But there is something I missed before my comment on FS#11737. The new -Qu ignores replacements. However, my comment there has some suggestions (independent from -Qu) which could "fix" this. (However this is a minor issue irl, imho) Bye
On Fri, Oct 31, 2008 at 10:31 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
On Fri, Oct 24, 2008 at 12:53 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
This is a big behavior change (iirc it restores the old behavior). Opinions?
This is fine for me. But that means we consider bug 7884 as invalid, which was opened by Dan. So as I said in the last comment of that bug, we have to wait for his input :)
Damn, this is a huge code cleanup. I like it. I've pulled it into my working branch (the latest version).
One thing I noticed and/or thought of- should we make the return status of this command different depending on whether there are upgrades available? That would make this super-easy to wrap in some sort of "up2date" script or something rather than having to parse the output.
This is a good idea. But there is something I missed before my comment on FS#11737. The new -Qu ignores replacements. However, my comment there has some suggestions (independent from -Qu) which could "fix" this. (However this is a minor issue irl, imho)
Hmm, this isn't quite what I expected either. Can we clean up this garbage in any way? $ ./src/pacman/pacman -Qu warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1) warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: namcap: local (2.1-2) is newer than extra (2.1-1) warning: openoffice-base: local (3.0.0-3) is newer than extra (3.0.0-2) warning: pacman-git: local (20081031-1) is newer than pacman-git-64 (20081028-1) warning: pycairo: local (1.6.4-2) is newer than extra (1.6.4-1) warning: pygobject: local (2.15.4-2) is newer than extra (2.15.4-1) warning: pygtk: local (2.13.0-2) is newer than extra (2.13.0-1) warning: python: local (2.6-2) is newer than extra (2.5.2-5) warning: python-numeric: local (24.2-3) is newer than extra (24.2-2) warning: sonata: local (1.5.3-2) is newer than extra (1.5.3-1) warning: vi: local (7.2.25-1) is newer than core (7.1.330-1) warning: vim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: vte: local (0.17.4-2) is newer than extra (0.17.4-1) -Dan
Dan McGee wrote:
On Fri, Oct 31, 2008 at 10:31 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
On Fri, Oct 24, 2008 at 12:53 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
This is a big behavior change (iirc it restores the old behavior). Opinions?
This is fine for me. But that means we consider bug 7884 as invalid, which was opened by Dan. So as I said in the last comment of that bug, we have to wait for his input :)
Damn, this is a huge code cleanup. I like it. I've pulled it into my working branch (the latest version).
One thing I noticed and/or thought of- should we make the return status of this command different depending on whether there are upgrades available? That would make this super-easy to wrap in some sort of "up2date" script or something rather than having to parse the output.
This is a good idea. But there is something I missed before my comment on FS#11737. The new -Qu ignores replacements. However, my comment there has some suggestions (independent from -Qu) which could "fix" this. (However this is a minor issue irl, imho)
Hmm, this isn't quite what I expected either. Can we clean up this garbage in any way?
$ ./src/pacman/pacman -Qu warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1) warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: namcap: local (2.1-2) is newer than extra (2.1-1) warning: openoffice-base: local (3.0.0-3) is newer than extra (3.0.0-2) warning: pacman-git: local (20081031-1) is newer than pacman-git-64 (20081028-1) warning: pycairo: local (1.6.4-2) is newer than extra (1.6.4-1) warning: pygobject: local (2.15.4-2) is newer than extra (2.15.4-1) warning: pygtk: local (2.13.0-2) is newer than extra (2.13.0-1) warning: python: local (2.6-2) is newer than extra (2.5.2-5) warning: python-numeric: local (24.2-3) is newer than extra (24.2-2) warning: sonata: local (1.5.3-2) is newer than extra (1.5.3-1) warning: vi: local (7.2.25-1) is newer than core (7.1.330-1) warning: vim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: vte: local (0.17.4-2) is newer than extra (0.17.4-1)
They all look like python rebuilds from [testing]. Are you using a local conf file there which has testing disabled? Allan
On Sat, Nov 1, 2008 at 7:48 AM, Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
On Fri, Oct 31, 2008 at 10:31 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
On Fri, Oct 24, 2008 at 12:53 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
This is a big behavior change (iirc it restores the old behavior). Opinions?
This is fine for me. But that means we consider bug 7884 as invalid, which was opened by Dan. So as I said in the last comment of that bug, we have to wait for his input :)
Damn, this is a huge code cleanup. I like it. I've pulled it into my working branch (the latest version).
One thing I noticed and/or thought of- should we make the return status of this command different depending on whether there are upgrades available? That would make this super-easy to wrap in some sort of "up2date" script or something rather than having to parse the output.
This is a good idea. But there is something I missed before my comment on FS#11737. The new -Qu ignores replacements. However, my comment there has some suggestions (independent from -Qu) which could "fix" this. (However this is a minor issue irl, imho)
Hmm, this isn't quite what I expected either. Can we clean up this garbage in any way?
$ ./src/pacman/pacman -Qu warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1) warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: namcap: local (2.1-2) is newer than extra (2.1-1) warning: openoffice-base: local (3.0.0-3) is newer than extra (3.0.0-2) warning: pacman-git: local (20081031-1) is newer than pacman-git-64 (20081028-1) warning: pycairo: local (1.6.4-2) is newer than extra (1.6.4-1) warning: pygobject: local (2.15.4-2) is newer than extra (2.15.4-1) warning: pygtk: local (2.13.0-2) is newer than extra (2.13.0-1) warning: python: local (2.6-2) is newer than extra (2.5.2-5) warning: python-numeric: local (24.2-3) is newer than extra (24.2-2) warning: sonata: local (1.5.3-2) is newer than extra (1.5.3-1) warning: vi: local (7.2.25-1) is newer than core (7.1.330-1) warning: vim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: vte: local (0.17.4-2) is newer than extra (0.17.4-1)
They all look like python rebuilds from [testing]. Are you using a local conf file there which has testing disabled?
Oh, I know exactly what they are- sorry for not being more descriptive. I was just pointing to the fact that this new -Qu operation even prints these guys, as no other query operation AFAIK would perform similar behavior. It seems irrelevant from the "-u as a filter" point of view. (And the reason you see these is because my testing repo is much more up to date than my "regular" repos) -Dan
Hmm, this isn't quite what I expected either. Can we clean up this garbage in any way?
$ ./src/pacman/pacman -Qu warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1) warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: namcap: local (2.1-2) is newer than extra (2.1-1) warning: openoffice-base: local (3.0.0-3) is newer than extra (3.0.0-2) warning: pacman-git: local (20081031-1) is newer than pacman-git-64 (20081028-1) warning: pycairo: local (1.6.4-2) is newer than extra (1.6.4-1) warning: pygobject: local (2.15.4-2) is newer than extra (2.15.4-1) warning: pygtk: local (2.13.0-2) is newer than extra (2.13.0-1) warning: python: local (2.6-2) is newer than extra (2.5.2-5) warning: python-numeric: local (24.2-3) is newer than extra (24.2-2) warning: sonata: local (1.5.3-2) is newer than extra (1.5.3-1) warning: vi: local (7.2.25-1) is newer than core (7.1.330-1) warning: vim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: vte: local (0.17.4-2) is newer than extra (0.17.4-1)
-Dan
1. Since I am lazy, I first try with the easiest solution. What about completely removing these messages? Are these useful with -Su at all? (The old -Qu printed these messages as well, bacause it was a simulation of -Su). 2. We could disable all warnings like with -Sp. 3. Most complicated: Give a new parameter to sync_newversion. This could fix the possible duplicated "pacman is newer than extra" message on -Su. Which solution do you prefer?
Hmm, this isn't quite what I expected either. Can we clean up this garbage in any way?
$ ./src/pacman/pacman -Qu warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1) warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: namcap: local (2.1-2) is newer than extra (2.1-1) warning: openoffice-base: local (3.0.0-3) is newer than extra (3.0.0-2) warning: pacman-git: local (20081031-1) is newer than pacman-git-64 (20081028-1) warning: pycairo: local (1.6.4-2) is newer than extra (1.6.4-1) warning: pygobject: local (2.15.4-2) is newer than extra (2.15.4-1) warning: pygtk: local (2.13.0-2) is newer than extra (2.13.0-1) warning: python: local (2.6-2) is newer than extra (2.5.2-5) warning: python-numeric: local (24.2-3) is newer than extra (24.2-2) warning: sonata: local (1.5.3-2) is newer than extra (1.5.3-1) warning: vi: local (7.2.25-1) is newer than core (7.1.330-1) warning: vim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: vte: local (0.17.4-2) is newer than extra (0.17.4-1)
-Dan
1. Since I am lazy, I first try with the easiest solution. What about completely removing these messages? Are these useful with -Su at all? (The old -Qu printed these messages as well, bacause it was a simulation of -Su). I personally find these messages helpful in the -Su case- when crazy
On Sat, Nov 1, 2008 at 8:16 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote: things like the above come up, you know something is up with your mirrors and whatnot.
2. We could disable all warnings like with -Sp. Never was too fond of this either. Seems hackish as is.
3. Most complicated: Give a new parameter to sync_newversion. This could fix the possible duplicated "pacman is newer than extra" message on -Su. This seems really ugly.
Wow, I'm a negative Nancy here. What if we proceed with 1 (so remove these things from alpm_sync_newversion), but somehow in sysupgrade we still can have this relevant info? I don't know if that is even possible. -Dan
Sat, 1 Nov 2008 08:19:51 -0500 -n "Dan McGee" <dpmcgee@gmail.com> írta:
Hmm, this isn't quite what I expected either. Can we clean up this garbage in any way?
$ ./src/pacman/pacman -Qu warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1) warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: namcap: local (2.1-2) is newer than extra (2.1-1) warning: openoffice-base: local (3.0.0-3) is newer than extra (3.0.0-2) warning: pacman-git: local (20081031-1) is newer than pacman-git-64 (20081028-1) warning: pycairo: local (1.6.4-2) is newer than extra (1.6.4-1) warning: pygobject: local (2.15.4-2) is newer than extra (2.15.4-1) warning: pygtk: local (2.13.0-2) is newer than extra (2.13.0-1) warning: python: local (2.6-2) is newer than extra (2.5.2-5) warning: python-numeric: local (24.2-3) is newer than extra (24.2-2) warning: sonata: local (1.5.3-2) is newer than extra (1.5.3-1) warning: vi: local (7.2.25-1) is newer than core (7.1.330-1) warning: vim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: vte: local (0.17.4-2) is newer than extra (0.17.4-1)
-Dan
1. Since I am lazy, I first try with the easiest solution. What about completely removing these messages? Are these useful with -Su at all? (The old -Qu printed these messages as well, bacause it was a simulation of -Su). I personally find these messages helpful in the -Su case- when crazy
On Sat, Nov 1, 2008 at 8:16 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote: things like the above come up, you know something is up with your mirrors and whatnot.
2. We could disable all warnings like with -Sp. Never was too fond of this either. Seems hackish as is.
3. Most complicated: Give a new parameter to sync_newversion. This could fix the possible duplicated "pacman is newer than extra" message on -Su. This seems really ugly.
Wow, I'm a negative Nancy here. What if we proceed with 1 (so remove these things from alpm_sync_newversion), but somehow in sysupgrade we still can have this relevant info? I don't know if that is even possible.
Without 3. this seems impossible. Then we should reimplement sync_newversion inside sync_sysupgrade (and may rename sync_newversion to ~pkg_outdated) or add a new out param (cmp) to it... Btw, sync_newversion is quite simple function (until we don't merge replacement stuff into it. I referred to FS#11737 here.) My vote is 2., even if it is hackish. In my mind "warnings" are just "additional info" messages, they never indicate important things (those are errors).
2008/11/1 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
Sat, 1 Nov 2008 08:19:51 -0500 -n "Dan McGee" <dpmcgee@gmail.com> írta:
Hmm, this isn't quite what I expected either. Can we clean up this garbage in any way?
$ ./src/pacman/pacman -Qu warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1) warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: namcap: local (2.1-2) is newer than extra (2.1-1) warning: openoffice-base: local (3.0.0-3) is newer than extra (3.0.0-2) warning: pacman-git: local (20081031-1) is newer than pacman-git-64 (20081028-1) warning: pycairo: local (1.6.4-2) is newer than extra (1.6.4-1) warning: pygobject: local (2.15.4-2) is newer than extra (2.15.4-1) warning: pygtk: local (2.13.0-2) is newer than extra (2.13.0-1) warning: python: local (2.6-2) is newer than extra (2.5.2-5) warning: python-numeric: local (24.2-3) is newer than extra (24.2-2) warning: sonata: local (1.5.3-2) is newer than extra (1.5.3-1) warning: vi: local (7.2.25-1) is newer than core (7.1.330-1) warning: vim: local (7.2.25-1) is newer than extra (7.1.330-1) warning: vte: local (0.17.4-2) is newer than extra (0.17.4-1)
-Dan
1. Since I am lazy, I first try with the easiest solution. What about completely removing these messages? Are these useful with -Su at all? (The old -Qu printed these messages as well, bacause it was a simulation of -Su). I personally find these messages helpful in the -Su case- when crazy
On Sat, Nov 1, 2008 at 8:16 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote: things like the above come up, you know something is up with your mirrors and whatnot.
2. We could disable all warnings like with -Sp. Never was too fond of this either. Seems hackish as is.
3. Most complicated: Give a new parameter to sync_newversion. This could fix the possible duplicated "pacman is newer than extra" message on -Su. This seems really ugly.
Wow, I'm a negative Nancy here. What if we proceed with 1 (so remove these things from alpm_sync_newversion), but somehow in sysupgrade we still can have this relevant info? I don't know if that is even possible.
Without 3. this seems impossible. Then we should reimplement sync_newversion inside sync_sysupgrade (and may rename sync_newversion to ~pkg_outdated) or add a new out param (cmp) to it... Btw, sync_newversion is quite simple function (until we don't merge replacement stuff into it. I referred to FS#11737 here.)
My vote is 2., even if it is hackish. In my mind "warnings" are just "additional info" messages, they never indicate important things (those are errors).
This just got me tonight. Should we just go with two, or can we buffer things to order them right or something? I'm not sure. The other option would be to use stdout and stderr in a slightly better fashion. -Dan
participants (4)
-
Allan McRae
-
Dan McGee
-
Nagy Gabor
-
Xavier