On 9/28/07, Xavier 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 :

...

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 9/29/07, Xavier 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 9/29/07, Xavier 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 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 9/29/07, Roman Kyrylych wrote:

2007/9/28, Xavier :

...

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, Dan McGee wrote:

On 10/2/07, Aaron Griffin wrote:

...

On 9/29/07, Roman Kyrylych wrote:

...

2007/9/28, Xavier :

...

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 10/3/07, Miklos Vajna wrote:

On Tue, Oct 02, 2007 at 05:47:30PM -0500, Dan McGee 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?

2007/10/3, Dan McGee :

-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 (Роман Кирилич)