[pacman-dev] -Qu vs -Su
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here. The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue? The description of -Qu says : -u, --upgrades list all packages that can be upgraded IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu. Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n] But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here.
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not.
IMHO -Qu is needless [I've never used that]. -Qu should do the same as alpm_sync_upgrade with some automatic answers (duplicated code or tricky transaction manipulations, grr), so user can also do -Su and break the transaction.
My first question : is that really an issue?
IMHO yes;-) However, in most cases the "output of -Su" == "output of current -Qu" [if the user's database is not broken and updated version of a local package doesn't need some extra dependencies <=> upgrading all local package is enough to satisfy dependencies]
The description of -Qu says : -u, --upgrades list all packages that can be upgraded
IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu.
Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n]
But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Fri, Sep 28, 2007 at 11:20:08PM +0200, Nagy Gabor wrote:
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not.
IMHO -Qu is needless [I've never used that]. -Qu should do the same as alpm_sync_upgrade with some automatic answers (duplicated code or tricky transaction manipulations, grr), so user can also do -Su and break the transaction.
I never used -Qu either. But I believe it's used by a few package upgrade notifiers. duplicated code vs tricky transaction manipulations, I think that sums up the problem well. I wanted to avoid the first, and Aaron want to avoid the second..
My first question : is that really an issue?
IMHO yes;-) However, in most cases the "output of -Su" == "output of current -Qu" [if the user's database is not broken and updated version of a local package doesn't need some extra dependencies <=> upgrading all local package is enough to satisfy dependencies]
You are right. There shouldn't be any differences in most cases, only from times to times, which is also why it's not a big deal.
On 9/28/07, Xavier <shiningxc@gmail.com> wrote:
On Fri, Sep 28, 2007 at 11:20:08PM +0200, Nagy Gabor wrote:
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not.
IMHO -Qu is needless [I've never used that]. -Qu should do the same as alpm_sync_upgrade with some automatic answers (duplicated code or tricky transaction manipulations, grr), so user can also do -Su and break the transaction.
I never used -Qu either. But I believe it's used by a few package upgrade notifiers.
duplicated code vs tricky transaction manipulations, I think that sums up the problem well. I wanted to avoid the first, and Aaron want to avoid the second..
I think, what I really wanted to do is supplant the original code. The way we do transactions is so messy, I would rather have functional code that DOESN'T use our hackey transactions and add it in later.
2007/9/28, Xavier <shiningxc@gmail.com>:
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here.
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue?
The description of -Qu says : -u, --upgrades list all packages that can be upgraded
IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu.
Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n]
But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
I also quote Aaron's comment from Flyspray:
I want one function that says "give me a list of packages that are upgradable". This function can be used in -Qu (simply returning the list and printing), -Su (using the list as targets), and -Sup (returning the list and calling some public alpm_pkg_get_url() on each member).
A public accessor to get a URL for a package can make -Qu and -Sup almost the same, except with different output functions.
I uderstand "a list of packages that are upgradeable" as a list of _already_installed_ packages that have newer versions available or there are new packages that replace them. This is different from the list that -Su and -Sup gives, because they list packages that are _going_to_be_installed_, including new dependencies. And this is also different from -Qu. The description of -Qu says "list all packages that can be upgraded" But -Qu doesn't do this! It displays _new_versions_(and replacements)_ of currently installed packages. This is different. So I propose the function list_upgradeable_packages() to list those installed packages that are not in IgnorePkg and has either new version, replacement or older version with options=(force) available in repos. Then -Qu, -Su and -Sup should do the following with the result of that function: -Qu - just print the result -Su - use the result as a list of packages that are going to be upgraded (exactly the same as -S pkg1 pkg2 ... pkgN) -Sup - same as -Su just print URIs -- Roman Kyrylych (Роман Кирилич)
2007/9/28, Xavier <shiningxc@gmail.com>:
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here.
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue?
The description of -Qu says : -u, --upgrades list all packages that can be upgraded
IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu.
Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n]
But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
I want one function that says "give me a list of packages that are upgradable". This function can be used in -Qu (simply returning the list and
I also quote Aaron's comment from Flyspray: printing), -Su (using the list as targets), and -Sup (returning the list and calling some public alpm_pkg_get_url() on each member).
A public accessor to get a URL for a package can make -Qu and -Sup almost
the same, except with different output functions.
I uderstand "a list of packages that are upgradeable" as a list of _already_installed_ packages that have newer versions available or there are new packages that replace them. This is different from the list that -Su and -Sup gives, because they list packages that are _going_to_be_installed_, including new dependencies. And this is also different from -Qu. The description of -Qu says "list all packages that can be upgraded" But -Qu doesn't do this! It displays _new_versions_(and replacements)_ of currently installed packages. This is different.
So I propose the function list_upgradeable_packages() to list those installed packages that are not in IgnorePkg and has either new version, replacement or older version with options=(force) available in repos. Then -Qu, -Su and -Sup should do the following with the result of that function: -Qu - just print the result -Su - use the result as a list of packages that are going to be upgraded (exactly the same as -S pkg1 pkg2 ... pkgN) -Sup - same as -Su just print URIs My opinion: The description of -Qu should say : -u, --upgrades list outdated packages and other switches should be able to used with -Qu, such as -i etc. etc.
User can use -Su if he want to see the to-be-installed packages, then answer no to the "proceed question". A bit off in this thread, but the current command-line handling of pacman is chaotic, for example the bahaviour of -Quil is not defined. We should restructure a bit, we should categorize options: (my example assumes -S) -operation: -l, -i, -c, -l, -p, -s, -y ... <- more than one allowed (pacman try to do all requested operations) -loadtarget/targettype-modifier options, -g, (--provider), -u (!!) ... <- only one allowed -trans_prepare/new-target-pull options: -d, (--noconflict option), -e ... <- more than one allowed -trans_commit options: -f, --asdeps, -w (do nothing) ... <- more than one allowed As an example, I explain what should pacman -Quetcl do: List all explicitly installed outdated not-a-dependency-of-other packages and show their changlogs and filelists ;-) Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Sat, Sep 29, 2007 at 01:48:29PM +0200, Nagy Gabor wrote:
A bit off in this thread, but the current command-line handling of pacman is chaotic, for example the bahaviour of -Quil is not defined. We should restructure a bit, we should categorize options: (my example assumes -S) -operation: -l, -i, -c, -l, -p, -s, -y ... <- more than one allowed (pacman try to do all requested operations) -loadtarget/targettype-modifier options, -g, (--provider), -u (!!) ... <- only one allowed -trans_prepare/new-target-pull options: -d, (--noconflict option), -e ... <- more than one allowed -trans_commit options: -f, --asdeps, -w (do nothing) ... <- more than one allowed As an example, I explain what should pacman -Quetcl do: List all explicitly installed outdated not-a-dependency-of-other packages and show their changlogs and filelists ;-)
I think that's a good idea, but a lot of work again :)
On 9/29/07, Xavier <shiningxc@gmail.com> wrote:
On Sat, Sep 29, 2007 at 01:48:29PM +0200, Nagy Gabor wrote:
A bit off in this thread, but the current command-line handling of pacman is chaotic, for example the bahaviour of -Quil is not defined. We should restructure a bit, we should categorize options: (my example assumes -S) -operation: -l, -i, -c, -l, -p, -s, -y ... <- more than one allowed (pacman try to do all requested operations) -loadtarget/targettype-modifier options, -g, (--provider), -u (!!) ... <- only one allowed -trans_prepare/new-target-pull options: -d, (--noconflict option), -e ... <- more than one allowed -trans_commit options: -f, --asdeps, -w (do nothing) ... <- more than one allowed As an example, I explain what should pacman -Quetcl do: List all explicitly installed outdated not-a-dependency-of-other packages and show their changlogs and filelists ;-)
I think that's a good idea, but a lot of work again :)
It's always "a lot of work". C'est la vie. This is why Dan and I like to harp on people for patches. We're just two guys, and we both have full time jobs (ok, I now have a second job if you look at the main Arch page) and social lives. It's hard to do everything everyone wants. That's also why I love when people run their own git branches. I don't have to do much extra. I remote update and voila! I have all your work to import. It's amazing. Keep up good the work guys.
On Mon, Oct 01, 2007 at 02:53:26PM -0500, Aaron Griffin wrote:
It's always "a lot of work". C'est la vie.
This is why Dan and I like to harp on people for patches. We're just two guys, and we both have full time jobs (ok, I now have a second job if you look at the main Arch page) and social lives.
Well, yes, it already seems you had way too much to deal with. But I was wondering how harder it'll be with your new status. Though, I was thinking that maybe things will not change too much. It's not like Judd stopped working on Arch today. Afaik, he has been inactive for a while now. Anyway, it's nice to see you are up to handle this :) Sometimes, I am wondering if it wouldn't be nicer to have a full time job for working on OSS. I'm not sure how uncommon that is though. And that's also totally off-topic :P But about pacman, I agree the manpower seems quite limited. There should probably be more contributors, but that would also mean more patches to review, which is a time consuming task. And Dan or you can't be easily replaced, since this requires skills and experience on the project..
On 9/29/07, Xavier <shiningxc@gmail.com> wrote:
On Sat, Sep 29, 2007 at 01:48:29PM +0200, Nagy Gabor wrote:
A bit off in this thread, but the current command-line handling of pacman is chaotic, for example the bahaviour of -Quil is not defined. We should restructure a bit, we should categorize options: (my example assumes -S) -operation: -l, -i, -c, -l, -p, -s, -y ... <- more than one allowed (pacman try to do all requested operations) -loadtarget/targettype-modifier options, -g, (--provider), -u (!!) ... <- only one allowed -trans_prepare/new-target-pull options: -d, (--noconflict option), -e ... <- more than one allowed -trans_commit options: -f, --asdeps, -w (do nothing) ... <- more than one allowed As an example, I explain what should pacman -Quetcl do: List all explicitly installed outdated not-a-dependency-of-other packages and show their changlogs and filelists ;-)
I think that's a good idea, but a lot of work again :)
It's always "a lot of work". C'est la vie.
This is why Dan and I like to harp on people for patches. We're just two guys, and we both have full time jobs (ok, I now have a second job if you look at the main Arch page) and social lives.
It's hard to do everything everyone wants.
That's also why I love when people run their own git branches. I don't have to do much extra. I remote update and voila! I have all your work to import.
It's amazing.
Keep up good the work guys.
OK, I will explain a viewpoint of a patch-sender ;-) First of all, all of us have few freetime. To tell the truth I would radically rewrite some parts of pacman. This could be done at one night (in one-person hobby-projects (unlike pacman) the maintainer can do this easily ;-). But I cannot do that, because: -if I send a huge patch, you may not like the result and reject my patch, so I wasted a lot time [so I won't send huge patches] -if I send smaller patches depending on each other (to prevent myself from useless work) I have to wait a lot for your review/apply, and the one-night-work may become a six-months-work ... [my deps.c and sync.c patches were sent about 2 months ago, and I'm waiting now for your apply/reject, I cannot continue my work until your decision...] So patch-senders cannot help more, we just send patches... Please don't ask us to create a git repo etc., that is needless, if you can _easily_ "decode" our patches, that should be enough. I appreciate your work on pacman as a developer (!many thanks, again!), but you should see that sometimes you and Dan slow down the development (by sitting on patches). I didn't want to hurt anybody, this was a criticism of a development _model_. However, I cannot suggest better... but I would give git access to some talented&enthusiastic guys <- not me;-). Because if I have not enough time for a project, I will search for other guys, who will enjoy help me <- Aaron: cf. mc Arch package bugs ;-). Note: English is not my native language, so I cannot express myself as clearly as I could in Hungarian, so my e-mail may be hurtful or whatever, sry. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On 10/2/07, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
On 9/29/07, Xavier <shiningxc@gmail.com> wrote:
On Sat, Sep 29, 2007 at 01:48:29PM +0200, Nagy Gabor wrote:
A bit off in this thread, but the current command-line handling of pacman is chaotic, for example the bahaviour of -Quil is not defined. We should restructure a bit, we should categorize options: (my example assumes -S) -operation: -l, -i, -c, -l, -p, -s, -y ... <- more than one allowed (pacman try to do all requested operations) -loadtarget/targettype-modifier options, -g, (--provider), -u (!!) ... <- only one allowed -trans_prepare/new-target-pull options: -d, (--noconflict option), -e ... <- more than one allowed -trans_commit options: -f, --asdeps, -w (do nothing) ... <- more than one allowed As an example, I explain what should pacman -Quetcl do: List all explicitly installed outdated not-a-dependency-of-other packages and show their changlogs and filelists ;-)
I think that's a good idea, but a lot of work again :)
It's always "a lot of work". C'est la vie.
This is why Dan and I like to harp on people for patches. We're just two guys, and we both have full time jobs (ok, I now have a second job if you look at the main Arch page) and social lives.
It's hard to do everything everyone wants.
That's also why I love when people run their own git branches. I don't have to do much extra. I remote update and voila! I have all your work to import.
It's amazing.
Keep up good the work guys.
OK, I will explain a viewpoint of a patch-sender ;-)
First of all, all of us have few freetime.
To tell the truth I would radically rewrite some parts of pacman. This could be done at one night (in one-person hobby-projects (unlike pacman) the maintainer can do this easily ;-). But I cannot do that, because: -if I send a huge patch, you may not like the result and reject my patch, so I wasted a lot time [so I won't send huge patches] -if I send smaller patches depending on each other (to prevent myself from useless work) I have to wait a lot for your review/apply, and the one-night-work may become a six-months-work ... [my deps.c and sync.c patches were sent about 2 months ago, and I'm waiting now for your apply/reject, I cannot continue my work until your decision...]
So patch-senders cannot help more, we just send patches... Please don't ask us to create a git repo etc., that is needless, if you can _easily_ "decode" our patches, that should be enough. I appreciate your work on pacman as a developer (!many thanks, again!), but you should see that sometimes you and Dan slow down the development (by sitting on patches).
I didn't want to hurt anybody, this was a criticism of a development _model_. However, I cannot suggest better... but I would give git access to some talented&enthusiastic guys <- not me;-). Because if I have not enough time for a project, I will search for other guys, who will enjoy help me <- Aaron: cf. mc Arch package bugs ;-). Note: English is not my native language, so I cannot express myself as clearly as I could in Hungarian, so my e-mail may be hurtful or whatever, sry.
No no, hey - don't get me wrong. I totally "get" where you're coming from, BUT, the real issue here is not "will this get accepted or not" but "how much more work do I have to do". The simple fact is this. We have a lot of work to do. If you have idea, and don't want to submit patches for them, then there's not much we can do. So what we have to do instead is read through this email, think "that's a good idea", respond, try and figure out how much work it would take, and fit it into all the other crap we should be doing. Not only does sending patches help us in that we don't have to do the actual work, but it helps us with all the mental administrava we'd have to do to figure out if we should or shouldn't do what you suggest. The comment you made about big patches is important too. If you make big changes and they get rejected it's a lot of lost work... so submit smaller changesets. "One patch per feature" is the adage. The more and more ideas that are pumped out to this list, the more confused we get, and the harder it is to keep up. It's like.... if I throw a baseball at you, you might catch it, but if I throw 50, you won't catch them all. This is open source. Ideas are cheap. EVERYONE has ideas. Everything thinks something should be changed. Most of these ideas aren't original either. What gets you recognized in open source is NOT ideas and talk. It's work.
On Tue, Oct 02, 2007 at 12:36:00PM +0200, Nagy Gabor wrote:
So patch-senders cannot help more, we just send patches... Please don't ask us to create a git repo etc., that is needless, if you can _easily_ "decode" our patches, that should be enough. I appreciate your work on pacman as a developer (!many thanks, again!), but you should see that sometimes you and Dan slow down the development (by sitting on patches).
Actually, using a git repo helps here. It helps you storing your patches, organizing them in commits (and also commenting the commits), keeping your patches up-to-date with pacman git, keeping working om them when they are not fully finished or can be improved. Also, if several commits depend on each other, you usually just put them all in a branch. If they are not related, you can then start creating other branches. So I believe it can help, even if your repo isn't public. git can generate mails, ready to be sent to the ML :) Though, I have to admit I'm also curious to know what Dan or Aaron think about your last patches (available on the ML, or in my sync branch).
On 10/2/07, Xavier <shiningxc@gmail.com> wrote:
Though, I have to admit I'm also curious to know what Dan or Aaron think about your last patches (available on the ML, or in my sync branch).
Sadly, I haven't looked yet - as you're aware, my time is spotty these days, so I have to slot some pacman time into my schedule. I will take a look it all over, but won't be able to really sit down and do much until tomorrow night - or possibly late tonight. Also - I did want to thank you for all your work - because my time is so constrained these days, having a git repo helps IMMENSELY for reviewing these things.
On 9/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/28, Xavier <shiningxc@gmail.com>:
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here.
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue?
The description of -Qu says : -u, --upgrades list all packages that can be upgraded
IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu.
Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n]
But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
I also quote Aaron's comment from Flyspray:
I want one function that says "give me a list of packages that are upgradable". This function can be used in -Qu (simply returning the list and printing), -Su (using the list as targets), and -Sup (returning the list and calling some public alpm_pkg_get_url() on each member).
A public accessor to get a URL for a package can make -Qu and -Sup almost the same, except with different output functions.
I uderstand "a list of packages that are upgradeable" as a list of _already_installed_ packages that have newer versions available or there are new packages that replace them. This is different from the list that -Su and -Sup gives, because they list packages that are _going_to_be_installed_, including new dependencies. And this is also different from -Qu. The description of -Qu says "list all packages that can be upgraded" But -Qu doesn't do this! It displays _new_versions_(and replacements)_ of currently installed packages. This is different.
Yeah yeah - -Su would do one extra step in this case. It would take the list of packages and resolve the dependencies as well. We could, of course, do that as part of the "upgradable" check - I could see it either way. But, I guess, my point is this. The logic COULD be the same, and it would make much more sense to get a list of packages without the need for this clunky "transaction object", applying the transaction around the INSTALL only.
On 10/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 9/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/28, Xavier <shiningxc@gmail.com>:
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here.
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue?
The description of -Qu says : -u, --upgrades list all packages that can be upgraded
IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu.
Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n]
But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
I also quote Aaron's comment from Flyspray:
I want one function that says "give me a list of packages that are upgradable". This function can be used in -Qu (simply returning the list and printing), -Su (using the list as targets), and -Sup (returning the list and calling some public alpm_pkg_get_url() on each member).
A public accessor to get a URL for a package can make -Qu and -Sup almost the same, except with different output functions.
I uderstand "a list of packages that are upgradeable" as a list of _already_installed_ packages that have newer versions available or there are new packages that replace them. This is different from the list that -Su and -Sup gives, because they list packages that are _going_to_be_installed_, including new dependencies. And this is also different from -Qu. The description of -Qu says "list all packages that can be upgraded" But -Qu doesn't do this! It displays _new_versions_(and replacements)_ of currently installed packages. This is different.
Yeah yeah - -Su would do one extra step in this case. It would take the list of packages and resolve the dependencies as well.
We could, of course, do that as part of the "upgradable" check - I could see it either way.
But, I guess, my point is this. The logic COULD be the same, and it would make much more sense to get a list of packages without the need for this clunky "transaction object", applying the transaction around the INSTALL only.
I agree with Aaron here about the transaction object stuff. We shouldn't need that just to get a list of upgrades. I personally think -Su and -Qu (and their libalpm counterparts) should return the same list of packages to be installed, whether or not they are upgrades or pulled in deps. What is the disadvantage to this? -Qu was meant to be an alternative to canceling an -Su just because you wanted to see what needs upgrading. -Dan
On 10/2/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 9/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/28, Xavier <shiningxc@gmail.com>:
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here.
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue?
The description of -Qu says : -u, --upgrades list all packages that can be upgraded
IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu.
Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n]
But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
I also quote Aaron's comment from Flyspray:
I want one function that says "give me a list of packages that are upgradable". This function can be used in -Qu (simply returning the list and printing), -Su (using the list as targets), and -Sup (returning the list and calling some public alpm_pkg_get_url() on each member).
A public accessor to get a URL for a package can make -Qu and -Sup almost the same, except with different output functions.
I uderstand "a list of packages that are upgradeable" as a list of _already_installed_ packages that have newer versions available or there are new packages that replace them. This is different from the list that -Su and -Sup gives, because they list packages that are _going_to_be_installed_, including new dependencies. And this is also different from -Qu. The description of -Qu says "list all packages that can be upgraded" But -Qu doesn't do this! It displays _new_versions_(and replacements)_ of currently installed packages. This is different.
Yeah yeah - -Su would do one extra step in this case. It would take the list of packages and resolve the dependencies as well.
We could, of course, do that as part of the "upgradable" check - I could see it either way.
But, I guess, my point is this. The logic COULD be the same, and it would make much more sense to get a list of packages without the need for this clunky "transaction object", applying the transaction around the INSTALL only.
I agree with Aaron here about the transaction object stuff. We shouldn't need that just to get a list of upgrades.
I personally think -Su and -Qu (and their libalpm counterparts) should return the same list of packages to be installed, whether or not they are upgrades or pulled in deps. What is the disadvantage to this? -Qu was meant to be an alternative to canceling an -Su just because you wanted to see what needs upgrading.
Yeah, I don't see any reason why we couldn't resolve deps (which is the difference here, right?) while doing this, BUT I fear that makes more of a hassle. Adding functionality which allows us to get "upgradable" packages, AND functionality which allows us to resolve deps in a non-transactional, read-only manner would make all of our lives easier. Maybe I will have some time tonight to crack this out....
On Tue, Oct 02, 2007 at 05:47:30PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
I agree with Aaron here about the transaction object stuff. We shouldn't need that just to get a list of upgrades.
I personally think -Su and -Qu (and their libalpm counterparts) should return the same list of packages to be installed, whether or not they are upgrades or pulled in deps. What is the disadvantage to this? -Qu was meant to be an alternative to canceling an -Su just because you wanted to see what needs upgrading.
sorry for the dumb question but how do you deal with replacements? it would be ugly to have an interactive -Qu but without asking, you can't give a reasonable package list, hm. thanks, - VMiklos
On 10/3/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
On Tue, Oct 02, 2007 at 05:47:30PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
I agree with Aaron here about the transaction object stuff. We shouldn't need that just to get a list of upgrades.
I personally think -Su and -Qu (and their libalpm counterparts) should return the same list of packages to be installed, whether or not they are upgrades or pulled in deps. What is the disadvantage to this? -Qu was meant to be an alternative to canceling an -Su just because you wanted to see what needs upgrading.
sorry for the dumb question but how do you deal with replacements?
it would be ugly to have an interactive -Qu but without asking, you can't give a reasonable package list, hm.
Yeah - this is the only problem we have - currently -Qu assumes all ummm Yes answers, I believe. But that's still wrong. Any opinions here?
On Wed, Oct 03, 2007 at 10:48:50AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Yeah - this is the only problem we have - currently -Qu assumes all ummm Yes answers, I believe. But that's still wrong.
Any opinions here?
well, most users always just hit enter on such replace questions, so once there is a -Qu, the best can be the current situation i think (and the perfect solution is not having -Qu :) ) - VMiklos
2007/10/3, Dan McGee <dpmcgee@gmail.com>:
-Qu was meant to be an alternative to canceling an -Su just because you wanted to see what needs upgrading.
As I already explained above - the current description of -Qu is cofusing and wrong, IMO. And having -Qu just because you don't want to press N after -Su is ..ehm... redundant. Wouldn't be better that -Qu was modified as I suggested above? - which is essentially listing all installed packages that are outdated. -- Roman Kyrylych (Роман Кирилич)
I personally think -Su and -Qu (and their libalpm counterparts) should return the same list of packages to be installed, whether or not they are upgrades or pulled in deps. What is the disadvantage to this? -Qu was meant to be an alternative to canceling an -Su just because you wanted to see what needs upgrading.
-Dan Why do we need an alternative to cancelling -Su? ;-) As Xavier noted, -Su needs some user interaction, so -Qu cannot figure out what user would answer to pacman's questions (however, it can assume some default answers). Personally, I like the "outdated packages" meaning, so I would prefer that -Qu would act as a localdb/targetlist filter, like -Qt, -Qd, -Qe (so we don't need installed size information etc., but user can also use other command-line switches). Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
participants (6)
-
Aaron Griffin
-
Dan McGee
-
Miklos Vajna
-
Nagy Gabor
-
Roman Kyrylych
-
Xavier