[pacman-dev] [PATCH] -Qu rework - Pacman-dev - lists.archlinux.org

newer
[pacman-dev] [PATCH] Fix bug 9395...

[pacman-dev] [PATCH] -Qu rework

older
[pacman-dev] [GIT] The official...

Nagy Gabor

24 Oct 2008 24 Oct '08

2:09 a.m.

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/

Show replies by date

Xavier

24 Oct 24 Oct

7:53 a.m.

On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor 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 :)

Dan McGee

31 Oct 31 Oct

3:57 a.m.

On Fri, Oct 24, 2008 at 12:53 AM, Xavier wrote:

On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor 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

Nagy Gabor

4:31 p.m.

On Fri, Oct 24, 2008 at 12:53 AM, Xavier wrote:

...
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor 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

Dan McGee

1 Nov 1 Nov

1:41 p.m.

On Fri, Oct 31, 2008 at 10:31 AM, Nagy Gabor wrote:

...
On Fri, Oct 24, 2008 at 12:53 AM, Xavier wrote:

...
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor 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

Allan McRae

1:48 p.m.

Dan McGee wrote:

On Fri, Oct 31, 2008 at 10:31 AM, Nagy Gabor wrote:

...
...
On Fri, Oct 24, 2008 at 12:53 AM, Xavier wrote:

...
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor 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

Dan McGee

1:51 p.m.

On Sat, Nov 1, 2008 at 7:48 AM, Allan McRae wrote:

Dan McGee wrote:

...
On Fri, Oct 31, 2008 at 10:31 AM, Nagy Gabor wrote:

...
...
On Fri, Oct 24, 2008 at 12:53 AM, Xavier wrote:

...
On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor 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

Nagy Gabor

2:16 p.m.

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?

Dan McGee

2:19 p.m.

...
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 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

Nagy Gabor

2:36 p.m.

Sat, 1 Nov 2008 08:19:51 -0500 -n "Dan McGee" í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 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).

Dan McGee

13 Jan 13 Jan

5:48 a.m.

2008/11/1 Nagy Gabor :

Sat, 1 Nov 2008 08:19:51 -0500 -n "Dan McGee" í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 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

5581

Age (days ago)

5662

Last active (days ago)

Download

10 comments

4 participants

tags

participants (4)

Allan McRae
Dan McGee
Nagy Gabor
Xavier