FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 10-24-2008, 12:09 AM
Nagy Gabor
 
Default -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/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 10-24-2008, 05:53 AM
Xavier
 
Default -Qu rework

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
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 10-31-2008, 01:57 AM
"Dan McGee"
 
Default -Qu rework

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
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 10-31-2008, 02:31 PM
Nagy Gabor
 
Default -Qu rework

> 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
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 11-01-2008, 11:41 AM
"Dan McGee"
 
Default -Qu rework

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
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 11-01-2008, 11:48 AM
Allan McRae
 
Default -Qu rework

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



_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 11-01-2008, 11:51 AM
"Dan McGee"
 
Default -Qu rework

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
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 11-01-2008, 12:16 PM
Nagy Gabor
 
Default -Qu rework

> 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?
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 11-01-2008, 12:19 PM
"Dan McGee"
 
Default -Qu rework

On Sat, Nov 1, 2008 at 8:16 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
>> 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
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
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 11-01-2008, 12:36 PM
Nagy Gabor
 
Default -Qu rework

Sat, 1 Nov 2008 08:19:51 -0500 -n
"Dan McGee" <dpmcgee@gmail.com> írta:

> On Sat, Nov 1, 2008 at 8:16 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu>
> wrote:
> >> 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
> 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).
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 08:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org