[pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

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

Connor Behan

14 Mar 2013 14 Mar '13

6:37 a.m.

Calling pacman -Sp and pacman -Sup are guaranteed not to install a package. So the user's IgnorePkg pref is respected regardless of whether or not we print the mirror location. Therefore we do so in the case of -Sp as this gives the full information requested by the user. We avoid doing so in the case of -Sup as this would mislead the user into thinking that the upgrade is bigger than it really is. This fixes an edge case with devtools. Signed-off-by: Connor Behan --- src/pacman/conf.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 3f1b1c3..99e6af1 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -1010,6 +1010,13 @@ int parseconfig(const char *file) if((ret = _parseconfig(file, §ion, 1, 0))) { return ret; } + + /* #FS#34066 - Querying URLs for packages specified on the command line (even ignored ones) should succeed */ + if(config->print && !config->op_s_upgrade) { + config->ignorepkg = NULL; + config->ignoregrp = NULL; + } + if((ret = setup_libalpm())) { return ret; } -- 1.8.1.5

Show replies by date

Allan McRae

14 Mar 14 Mar

7:37 a.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On 14/03/13 16:37, Connor Behan wrote:

...

Calling pacman -Sp and pacman -Sup are guaranteed not to install a package. So the user's IgnorePkg pref is respected regardless of whether or not we print the mirror location. Therefore we do so in the case of -Sp as this gives the full information requested by the user. We avoid doing so in the case of -Sup as this would mislead the user into thinking that the upgrade is bigger than it really is. This fixes an edge case with devtools.

Signed-off-by: Connor Behan --- src/pacman/conf.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 3f1b1c3..99e6af1 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -1010,6 +1010,13 @@ int parseconfig(const char *file) if((ret = _parseconfig(file, §ion, 1, 0))) { return ret; } + + /* #FS#34066 - Querying URLs for packages specified on the command line (even ignored ones) should succeed */

Fine apart from the comment. I do not like referring to bug reports. The comment should stand alone in the code and not require referring elsewhere. Also, the comment is not quite right as "pacman -Sup foo" will still exclude "foo" if that is in IgnorePkg. How about: "Print URLs for all given packages on non-upgrade operations"? If that is OK, I can make the adjustment when I pull it.

...

+ if(config->print && !config->op_s_upgrade) { + config->ignorepkg = NULL; + config->ignoregrp = NULL; + } + if((ret = setup_libalpm())) { return ret; }

Connor Behan

7:51 a.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On 14/03/13 12:37 AM, Allan McRae wrote:

...

On 14/03/13 16:37, Connor Behan wrote:

...
Calling pacman -Sp and pacman -Sup are guaranteed not to install a package. So the user's IgnorePkg pref is respected regardless of whether or not we print the mirror location. Therefore we do so in the case of -Sp as this gives the full information requested by the user. We avoid doing so in the case of -Sup as this would mislead the user into thinking that the upgrade is bigger than it really is. This fixes an edge case with devtools.

Signed-off-by: Connor Behan --- src/pacman/conf.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 3f1b1c3..99e6af1 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -1010,6 +1010,13 @@ int parseconfig(const char *file) if((ret = _parseconfig(file, §ion, 1, 0))) { return ret; } + + /* #FS#34066 - Querying URLs for packages specified on the command line (even ignored ones) should succeed */ Fine apart from the comment. I do not like referring to bug reports. The comment should stand alone in the code and not require referring elsewhere.

Also, the comment is not quite right as "pacman -Sup foo" will still exclude "foo" if that is in IgnorePkg.

How about:

"Print URLs for all given packages on non-upgrade operations"?

If that is OK, I can make the adjustment when I pull it.

Yeah, that's a good replacement. I was modelling it after https://projects.archlinux.org/pacman.git/tree/src/pacman/sync.c#n644 in case you want to get rid of that too.

Xyne

7:55 a.m.

Allan McRae wrote:

...

On 14/03/13 16:37, Connor Behan wrote:

...
Calling pacman -Sp and pacman -Sup are guaranteed not to install a package. So the user's IgnorePkg pref is respected regardless of whether or not we print the mirror location. Therefore we do so in the case of -Sp as this gives the full information requested by the user. We avoid doing so in the case of -Sup as this would mislead the user into thinking that the upgrade is bigger than it really is. This fixes an edge case with devtools.

Signed-off-by: Connor Behan --- src/pacman/conf.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 3f1b1c3..99e6af1 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -1010,6 +1010,13 @@ int parseconfig(const char *file) if((ret = _parseconfig(file, §ion, 1, 0))) { return ret; } + + /* #FS#34066 - Querying URLs for packages specified on the command line (even ignored ones) should succeed */

Fine apart from the comment. I do not like referring to bug reports. The comment should stand alone in the code and not require referring elsewhere.

Also, the comment is not quite right as "pacman -Sup foo" will still exclude "foo" if that is in IgnorePkg.

How about:

"Print URLs for all given packages on non-upgrade operations"?

If that is OK, I can make the adjustment when I pull it.

...
+ if(config->print && !config->op_s_upgrade) { + config->ignorepkg = NULL; + config->ignoregrp = NULL; + } + if((ret = setup_libalpm())) { return ret; }

This may break simple scripts that naively parse the output (updaters, notifiers, downloaders, ...). While that is not officially supported there is really no reason to change expected behavior for this. I think a better approach would be to omit ignored packages unless they are explicitly included on the command line. Otherwise perhaps you could use a special argument to '--ignore' (or a custom option) to stop ignoring packages for a given operation (e.g. --ignore -). Both cases remain backwards compatible with past behavior and avoid surprises. Regards, Xyne

Xyne

8:08 a.m.

Xyne wrote:

...

This may break simple scripts that naively parse the output (updaters, notifiers, downloaders, ...). While that is not officially supported there is really no reason to change expected behavior for this. I think a better approach would be to omit ignored packages unless they are explicitly included on the command line. Otherwise perhaps you could use a special argument to '--ignore' (or a custom option) to stop ignoring packages for a given operation (e.g. --ignore -).

Both cases remain backwards compatible with past behavior and avoid surprises.

Regards, Xyne

Just to give a concrete example of how this applies, let's say that the user has ignored "foo". Running "pacman -Sp <group>" where foo is a member of <group> should not include foo in the output. It would also apply when printing groups that overlap with ignored groups. Allan McRae wrote:

...

I just realised that "pacman -Sp --ignore glibc glibc" makes little sense, so just -Sup case then.

In that case it doesn't, in others it does. Explicit "--ignore" options should override command-line arguments. For example, pacman -Sp --ignore foo $(pacman -Slq bar-repo) where foo is a member of [bar-repo]. Of course you can run the repo list through grep or some other filter, but it is logical to expect an "--ignore" option to force pacman to ignore a package and I think it would be consistent behavior.

Allan McRae

11:22 a.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On 14/03/13 18:08, Xyne wrote:

...

Xyne wrote:

...
This may break simple scripts that naively parse the output (updaters, notifiers, downloaders, ...). While that is not officially supported there is really no reason to change expected behavior for this. I think a better approach would be to omit ignored packages unless they are explicitly included on the command line. Otherwise perhaps you could use a special argument to '--ignore' (or a custom option) to stop ignoring packages for a given operation (e.g. --ignore -).

Both cases remain backwards compatible with past behavior and avoid surprises.

Regards, Xyne

Just to give a concrete example of how this applies, let's say that the user has ignored "foo". Running "pacman -Sp <group>" where foo is a member of <group> should not include foo in the output.

It would also apply when printing groups that overlap with ignored groups.

Allan McRae wrote:

...
I just realised that "pacman -Sp --ignore glibc glibc" makes little sense, so just -Sup case then.

In that case it doesn't, in others it does. Explicit "--ignore" options should override command-line arguments. For example,

pacman -Sp --ignore foo $(pacman -Slq bar-repo)

where foo is a member of [bar-repo]. Of course you can run the repo list through grep or some other filter, but it is logical to expect an "--ignore" option to force pacman to ignore a package and I think it would be consistent behavior.

Good catch. I had caught the the -Sup issue, but yes ignoring packages within groups are an issue I missed... Hence why this was delayed to 4.2. It would be good if a bug was filed to track exactly this issue (and not its consequences to devtools). Allan

Dave Reisner

2:30 p.m.

On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote:

...

Calling pacman -Sp and pacman -Sup are guaranteed not to install a package.

I feel the need to point out that --ignore guarantees that a package won't even be *downloaded*. Xyne already mentioned it, but I'll parrot his concern about this effectively changing command line API.

...

So the user's IgnorePkg pref is respected regardless of whether or not we print the mirror location. Therefore we do so in the case of -Sp as this gives the full information requested by the user. We avoid doing so in the case of -Sup as this would mislead the user into thinking that the upgrade is bigger than it really is. This fixes an edge case with devtools.

Signed-off-by: Connor Behan --- src/pacman/conf.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 3f1b1c3..99e6af1 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -1010,6 +1010,13 @@ int parseconfig(const char *file) if((ret = _parseconfig(file, §ion, 1, 0))) { return ret; } + + /* #FS#34066 - Querying URLs for packages specified on the command line (even ignored ones) should succeed */ + if(config->print && !config->op_s_upgrade) { + config->ignorepkg = NULL; + config->ignoregrp = NULL; + } + if((ret = setup_libalpm())) { return ret; } -- 1.8.1.5

Allan McRae

4:40 p.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On 15/03/13 00:30, Dave Reisner wrote:

...

On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote:

...
Calling pacman -Sp and pacman -Sup are guaranteed not to install a package.

I feel the need to point out that --ignore guarantees that a package won't even be *downloaded*. Xyne already mentioned it, but I'll parrot his concern about this effectively changing command line API.

Where do you get that guarantee? All the documentation says is: Instructs pacman to ignore any upgrades for this package when performing a --sysupgrade. So I am not even sure Xyne's example is valid, based purely on what this is documented to do... -Sp is not an --sysupgrade operation, and this patch specifically keeps --ignore for -Sup operations. So... to understand what people think pacman _should_ do, if "foo" (in group "bar") is in IgnorePkg: "-Sup" should not print a URL for foo (not up for debate...) "-Sp foo" should print a URL for foo (currently does not). What should "-Sp bar" print? From what is currently documented, it is not a --sysupgrade, so IgnorePkg should not have an effect. From what currently happens, it should not print a "foo" URL. Allan

Andrew Gregory

5:02 p.m.

On 03/15/13 at 02:40am, Allan McRae wrote:

...

On 15/03/13 00:30, Dave Reisner wrote:

...
On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote:

...
Calling pacman -Sp and pacman -Sup are guaranteed not to install a package.

I feel the need to point out that --ignore guarantees that a package won't even be *downloaded*. Xyne already mentioned it, but I'll parrot his concern about this effectively changing command line API.

Where do you get that guarantee? All the documentation says is:

Instructs pacman to ignore any upgrades for this package when performing a --sysupgrade.

So I am not even sure Xyne's example is valid, based purely on what this is documented to do... -Sp is not an --sysupgrade operation, and this patch specifically keeps --ignore for -Sup operations.

So... to understand what people think pacman _should_ do, if "foo" (in group "bar") is in IgnorePkg:

"-Sup" should not print a URL for foo (not up for debate...)

"-Sp foo" should print a URL for foo (currently does not).

What should "-Sp bar" print? From what is currently documented, it is not a --sysupgrade, so IgnorePkg should not have an effect. From what currently happens, it should not print a "foo" URL.

Allan

"-Sp bar" should print a URL for foo. A sysupgrade is very different from syncing or removing a group, so IgnorePkg should only ignore upgrades not remove the package from group operations. The fact that IgnorePkg is applied to any operations other than sysupgrade is a bug. In fact, --ignore and IgnorePkg have no effect on removal which creates an odd disparity between syncing and removing groups. apg

Connor Behan

7:40 p.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On Thu, Mar 14, 2013 at 10:02 AM, Andrew Gregory

...

wrote:

...

On 03/15/13 at 02:40am, Allan McRae wrote:

...
On 15/03/13 00:30, Dave Reisner wrote:

...
On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote:

...
Calling pacman -Sp and pacman -Sup are guaranteed not to install a package.

I feel the need to point out that --ignore guarantees that a package won't even be *downloaded*. Xyne already mentioned it, but I'll parrot his concern about this effectively changing command line API.

Where do you get that guarantee? All the documentation says is:

Instructs pacman to ignore any upgrades for this package when performing a --sysupgrade.

So I am not even sure Xyne's example is valid, based purely on what this is documented to do... -Sp is not an --sysupgrade operation, and this patch specifically keeps --ignore for -Sup operations.

So... to understand what people think pacman _should_ do, if "foo" (in group "bar") is in IgnorePkg:

"-Sup" should not print a URL for foo (not up for debate...)

"-Sp foo" should print a URL for foo (currently does not).

What should "-Sp bar" print? From what is currently documented, it is not a --sysupgrade, so IgnorePkg should not have an effect. From what currently happens, it should not print a "foo" URL.

Allan

"-Sp bar" should print a URL for foo.

A sysupgrade is very different from syncing or removing a group, so IgnorePkg should only ignore upgrades not remove the package from group operations. The fact that IgnorePkg is applied to any operations other than sysupgrade is a bug. In fact, --ignore and IgnorePkg have no effect on removal which creates an odd disparity between syncing and removing groups.

apg

I could modify the patch so that it limits ignorepkg to packages beside --ignore rather than clearing it. I could also check the command line arguments so that if any of them are groups rather than packages, we just bail and forget about changing ignorepkg. This would make the patch less trivial but it would change as little of the API as possible. Now that Xyne has mentioned it, I actually like the current behaviour of not printing ignored URLs for group operations. If this has been a bug all along and the automation tools will have to be changed anyway then we are once again back to an easy patch.

Andrew Gregory

10:25 p.m.

On 03/14/13 at 12:40pm, Connor Behan wrote:

...

On Thu, Mar 14, 2013 at 10:02 AM, Andrew Gregory
...
wrote:

...
On 03/15/13 at 02:40am, Allan McRae wrote:

...
On 15/03/13 00:30, Dave Reisner wrote:

...
On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote:

...
Calling pacman -Sp and pacman -Sup are guaranteed not to install a package.

I feel the need to point out that --ignore guarantees that a package won't even be *downloaded*. Xyne already mentioned it, but I'll parrot his concern about this effectively changing command line API.

Where do you get that guarantee? All the documentation says is:

Instructs pacman to ignore any upgrades for this package when performing a --sysupgrade.

So I am not even sure Xyne's example is valid, based purely on what this is documented to do... -Sp is not an --sysupgrade operation, and this patch specifically keeps --ignore for -Sup operations.

So... to understand what people think pacman _should_ do, if "foo" (in group "bar") is in IgnorePkg:

"-Sup" should not print a URL for foo (not up for debate...)

"-Sp foo" should print a URL for foo (currently does not).

What should "-Sp bar" print? From what is currently documented, it is not a --sysupgrade, so IgnorePkg should not have an effect. From what currently happens, it should not print a "foo" URL.

Allan

"-Sp bar" should print a URL for foo.

A sysupgrade is very different from syncing or removing a group, so IgnorePkg should only ignore upgrades not remove the package from group operations. The fact that IgnorePkg is applied to any operations other than sysupgrade is a bug. In fact, --ignore and IgnorePkg have no effect on removal which creates an odd disparity between syncing and removing groups.

apg

I could modify the patch so that it limits ignorepkg to packages beside --ignore rather than clearing it. I could also check the command line arguments so that if any of them are groups rather than packages, we just bail and forget about changing ignorepkg. This would make the patch less trivial but it would change as little of the API as possible.

Now that Xyne has mentioned it, I actually like the current behaviour of not printing ignored URLs for group operations. If this has been a bug all along and the automation tools will have to be changed anyway then we are once again back to an easy patch.

Putting the issue of how much --ignore should do, I think the root issue is that pacman uses different default responses for --noconfirm and --print. --print uses alpm's default value, whereas --noconfirm uses a pacman-specific value. So "-S --noconfirm bar" would install foo but "-Sp bar" does not print foo. This is the same reason "-Sp foo" does not print foo. I see no reason why pacman shouldn't be using the same value for both, which, if I'm not mistaken, would fix your issue with devtools. apg

Connor Behan

15 Mar 15 Mar

1:32 a.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On 14/03/13 03:25 PM, Andrew Gregory wrote:

...

On 03/14/13 at 12:40pm, Connor Behan wrote:

...
On Thu, Mar 14, 2013 at 10:02 AM, Andrew Gregory
...
wrote: On 03/15/13 at 02:40am, Allan McRae wrote:

...
On 15/03/13 00:30, Dave Reisner wrote:

...
On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote:

...
Calling pacman -Sp and pacman -Sup are guaranteed not to install a package. I feel the need to point out that --ignore guarantees that a package won't even be *downloaded*. Xyne already mentioned it, but I'll parrot his concern about this effectively changing command line API.

Where do you get that guarantee? All the documentation says is:

Instructs pacman to ignore any upgrades for this package when performing a --sysupgrade.

So I am not even sure Xyne's example is valid, based purely on what this is documented to do... -Sp is not an --sysupgrade operation, and this patch specifically keeps --ignore for -Sup operations.

So... to understand what people think pacman _should_ do, if "foo" (in group "bar") is in IgnorePkg:

"-Sup" should not print a URL for foo (not up for debate...)

"-Sp foo" should print a URL for foo (currently does not).

What should "-Sp bar" print? From what is currently documented, it is not a --sysupgrade, so IgnorePkg should not have an effect. From what currently happens, it should not print a "foo" URL.

Allan

"-Sp bar" should print a URL for foo.

A sysupgrade is very different from syncing or removing a group, so IgnorePkg should only ignore upgrades not remove the package from group operations. The fact that IgnorePkg is applied to any operations other than sysupgrade is a bug. In fact, --ignore and IgnorePkg have no effect on removal which creates an odd disparity between syncing and removing groups.

apg

I could modify the patch so that it limits ignorepkg to packages beside --ignore rather than clearing it. I could also check the command line arguments so that if any of them are groups rather than packages, we just bail and forget about changing ignorepkg. This would make the patch less trivial but it would change as little of the API as possible.

Now that Xyne has mentioned it, I actually like the current behaviour of not printing ignored URLs for group operations. If this has been a bug all along and the automation tools will have to be changed anyway then we are once again back to an easy patch.

Putting the issue of how much --ignore should do, I think the root issue is that pacman uses different default responses for --noconfirm and --print. --print uses alpm's default value, whereas --noconfirm uses a pacman-specific value. So "-S --noconfirm bar" would install foo but "-Sp bar" does not print foo. This is the same reason "-Sp foo" does not print foo. I see no reason why pacman shouldn't be using the same value for both, which, if I'm not mistaken, would fix your issue with devtools.

apg

So if I read correctly, explicitly installing an ignored package or installing a group that contains an ignored package asks a yesno question. The question callback says to return without an answer if config->print is true. If we want to keep this behaviour (and not have the user prompted for pacman -Sp), we would just make libalpm default to install=1 like pacman would do being sure to set it back to 0 if prompt=0. This option seems like the best in terms of logic. We would treat --noconfirm and --print symmetrically and there wouldn't be spaghetti code checking for some esoteric use case. However it would introduce the same complication for scripts that Xyne was worried about.

Andrew Gregory

11:49 p.m.

On 03/14/13 at 06:32pm, Connor Behan wrote:

...

On 14/03/13 03:25 PM, Andrew Gregory wrote:

...
On 03/14/13 at 12:40pm, Connor Behan wrote:

...
I could modify the patch so that it limits ignorepkg to packages beside --ignore rather than clearing it. I could also check the command line arguments so that if any of them are groups rather than packages, we just bail and forget about changing ignorepkg. This would make the patch less trivial but it would change as little of the API as possible.

Now that Xyne has mentioned it, I actually like the current behaviour of not printing ignored URLs for group operations. If this has been a bug all along and the automation tools will have to be changed anyway then we are once again back to an easy patch.

Putting the issue of how much --ignore should do, I think the root issue is that pacman uses different default responses for --noconfirm and --print. --print uses alpm's default value, whereas --noconfirm uses a pacman-specific value. So "-S --noconfirm bar" would install foo but "-Sp bar" does not print foo. This is the same reason "-Sp foo" does not print foo. I see no reason why pacman shouldn't be using the same value for both, which, if I'm not mistaken, would fix your issue with devtools.

apg

So if I read correctly, explicitly installing an ignored package or installing a group that contains an ignored package asks a yesno question. The question callback says to return without an answer if config->print is true.

Yes, pacman's entire callback function is skipped entirely if --print is used, which is why pacman returns no response at all to alpm rather than the default response. Used with --noconfirm, pacman returns the default response.

...

If we want to keep this behaviour (and not have the user prompted for pacman -Sp), we would just make libalpm default to install=1 like pacman would do being sure to set it back to 0 if prompt=0. This option seems like the best in terms of logic. We would treat --noconfirm and --print symmetrically and there wouldn't be spaghetti code checking for some esoteric use case. However it would introduce the same complication for scripts that Xyne was worried about.

I don't think changing alpm's defaults is the correct solution here. I still see this as a purely frontend issue. The --print option already implies --noconfirm so the only reason I see for it to skip the callback altogether is to avoid printing the question. I think the proper solution is to find another way to suppress that output that allows pacman to return the default response to alpm. apg

Connor Behan

16 Mar 16 Mar

3:21 a.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On 15/03/13 04:49 PM, Andrew Gregory wrote:

...

...
On 14/03/13 03:25 PM, Andrew Gregory wrote:

...
On 03/14/13 at 12:40pm, Connor Behan wrote:

...
I could modify the patch so that it limits ignorepkg to packages beside --ignore rather than clearing it. I could also check the command line arguments so that if any of them are groups rather than packages, we just bail and forget about changing ignorepkg. This would make the patch less trivial but it would change as little of the API as possible.

Now that Xyne has mentioned it, I actually like the current behaviour of not printing ignored URLs for group operations. If this has been a bug all along and the automation tools will have to be changed anyway then we are once again back to an easy patch.

Putting the issue of how much --ignore should do, I think the root issue is that pacman uses different default responses for --noconfirm and --print. --print uses alpm's default value, whereas --noconfirm uses a pacman-specific value. So "-S --noconfirm bar" would install foo but "-Sp bar" does not print foo. This is the same reason "-Sp foo" does not print foo. I see no reason why pacman shouldn't be using the same value for both, which, if I'm not mistaken, would fix your issue with devtools.

apg

So if I read correctly, explicitly installing an ignored package or installing a group that contains an ignored package asks a yesno question. The question callback says to return without an answer if config->print is true. Yes, pacman's entire callback function is skipped entirely if --print is used, which is why pacman returns no response at all to alpm rather

On 03/14/13 at 06:32pm, Connor Behan wrote: than the default response. Used with --noconfirm, pacman returns the default response.

...
If we want to keep this behaviour (and not have the user prompted for pacman -Sp), we would just make libalpm default to install=1 like pacman would do being sure to set it back to 0 if prompt=0. This option seems like the best in terms of logic. We would treat --noconfirm and --print symmetrically and there wouldn't be spaghetti code checking for some esoteric use case. However it would introduce the same complication for scripts that Xyne was worried about.

I don't think changing alpm's defaults is the correct solution here. I still see this as a purely frontend issue. The --print option already implies --noconfirm so the only reason I see for it to skip the callback altogether is to avoid printing the question. I think the proper solution is to find another way to suppress that output that allows pacman to return the default response to alpm.

apg

Ok, so we fix it by making --print automatically imply --noconfirm? And not having the question callback check especially for --print?

Andrew Gregory

1:58 p.m.

On 03/15/13 at 08:21pm, Connor Behan wrote:

...

On 15/03/13 04:49 PM, Andrew Gregory wrote:

...
...
On 14/03/13 03:25 PM, Andrew Gregory wrote:

...
On 03/14/13 at 12:40pm, Connor Behan wrote:

...
I could modify the patch so that it limits ignorepkg to packages beside --ignore rather than clearing it. I could also check the command line arguments so that if any of them are groups rather than packages, we just bail and forget about changing ignorepkg. This would make the patch less trivial but it would change as little of the API as possible.

Now that Xyne has mentioned it, I actually like the current behaviour of not printing ignored URLs for group operations. If this has been a bug all along and the automation tools will have to be changed anyway then we are once again back to an easy patch.

Putting the issue of how much --ignore should do, I think the root issue is that pacman uses different default responses for --noconfirm and --print. --print uses alpm's default value, whereas --noconfirm uses a pacman-specific value. So "-S --noconfirm bar" would install foo but "-Sp bar" does not print foo. This is the same reason "-Sp foo" does not print foo. I see no reason why pacman shouldn't be using the same value for both, which, if I'm not mistaken, would fix your issue with devtools.

apg

So if I read correctly, explicitly installing an ignored package or installing a group that contains an ignored package asks a yesno question. The question callback says to return without an answer if config->print is true. Yes, pacman's entire callback function is skipped entirely if --print is used, which is why pacman returns no response at all to alpm rather

On 03/14/13 at 06:32pm, Connor Behan wrote: than the default response. Used with --noconfirm, pacman returns the default response.

...
If we want to keep this behaviour (and not have the user prompted for pacman -Sp), we would just make libalpm default to install=1 like pacman would do being sure to set it back to 0 if prompt=0. This option seems like the best in terms of logic. We would treat --noconfirm and --print symmetrically and there wouldn't be spaghetti code checking for some esoteric use case. However it would introduce the same complication for scripts that Xyne was worried about.

I don't think changing alpm's defaults is the correct solution here. I still see this as a purely frontend issue. The --print option already implies --noconfirm so the only reason I see for it to skip the callback altogether is to avoid printing the question. I think the proper solution is to find another way to suppress that output that allows pacman to return the default response to alpm.

apg

Ok, so we fix it by making --print automatically imply --noconfirm? And not having the question callback check especially for --print?

--print already implies --noconfirm, no need to do anything there. You'll still have to check for --print somewhere in the callback process to avoid showing the questions. It just needs to be more selective so that only the output is skipped, not the entire callback function. apg

Connor Behan

18 Mar 18 Mar

5:42 a.m.

New subject: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

On 16/03/13 06:58 AM, Andrew Gregory wrote:

...

--print already implies --noconfirm, no need to do anything there. You'll still have to check for --print somewhere in the callback process to avoid showing the questions. It just needs to be more selective so that only the output is skipped, not the entire callback function. apg :) Much better than what I originally had in mind... I will send a patch soon. For now I've opened a proper bug for this, 34351.

4069

Age (days ago)

4073

Last active (days ago)

List overview

Download

15 comments

5 participants

participants (5)

Allan McRae
Andrew Gregory
Connor Behan
Dave Reisner
Xyne