[pacman-dev] [RFC] New member selection when installing group
One part of what's on http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working is about proposing a new interactive selection for installing groups. I did not like the old one, because I don't want to answer 50 questions when I install one group with 50 members. This is ugly, and the selection is not easily reproducible, for example you cannot easily copy/paste the answers of one run to another. I think a text frontend really sucks for this kind of workflow, a graphical or at least ncurses frontend would do much better. But my new provision selection inspired to both Jakob and Dan that we could have the same for groups, so I went ahead and implemented it over the weekend. $ pacman -S base-devel :: There are 11 members in group base-devel: :: Repository testing 1) make :: Repository core 2) autoconf 3) automake 4) bison 5) fakeroot 6) flex 7) gcc 8) libtool 9) m4 10) patch 11) pkg-config Which ones do you want to install? Enter a number (default=all): Multiple choices are possible, separated by spaces. Either single number or a range a-b. Both single numbers and range can be negated with ^ prefix. Choices are applied successively, so each choice override previous ones (in case of conflict). If first choice is negative, all targets are implicitly selected, otherwise no target is implicitly selected. Examples : 1) 3 6 8 : install automake, flex and libtool 2) 2-11 : install all targets in core repo 3) ^1 or 1-11 ^1 : install everything but make (like 2)) 4) ^2-11 : install everything but targets 2-11, i.e. only testing/make is left No idea how practical / user-friendly it is, so feedback and testing welcome.
On 19.10.2010 21:25, Xavier Chantry wrote:
But my new provision selection inspired to both Jakob and Dan that we could have the same for groups, so I went ahead and implemented it over the weekend.
Do it like yaourt (it prompts the user when doing -Syu) and open an editor with one package per line. If a user doesn't want to install a certain package he can just delete or comment(#) the line. I don't know how to handle dependencies here (foo needs bar, but the user removes bar), but I think you could just ask for those with a simple yes/no afterwards. -- Florian Pritz -- {flo,bluewind}@server-speed.net
Florian Pritz wrote:
On 19.10.2010 21:25, Xavier Chantry wrote:
But my new provision selection inspired to both Jakob and Dan that we could have the same for groups, so I went ahead and implemented it over the weekend.
Do it like yaourt (it prompts the user when doing -Syu) and open an editor with one package per line. If a user doesn't want to install a certain package he can just delete or comment(#) the line.
I don't know how to handle dependencies here (foo needs bar, but the user removes bar), but I think you could just ask for those with a simple yes/no afterwards.
I did think some time ago that it should not be too hard to write a pacman wrapper handling interactive group install. But I did not know yaourt had that feature, that's interesting. I like 'rebase -i' a lot, never thought of using that for groups. But well, if it's already in yaourt, why bother doing the same thing again in pacman ?
On 20.10.2010 20:09, Xavier wrote:
Florian Pritz wrote:
On 19.10.2010 21:25, Xavier Chantry wrote:
But my new provision selection inspired to both Jakob and Dan that we could have the same for groups, so I went ahead and implemented it over the weekend.
Do it like yaourt (it prompts the user when doing -Syu) and open an editor with one package per line. If a user doesn't want to install a certain package he can just delete or comment(#) the line.
I don't know how to handle dependencies here (foo needs bar, but the user removes bar), but I think you could just ask for those with a simple yes/no afterwards.
I did think some time ago that it should not be too hard to write a pacman wrapper handling interactive group install. But I did not know yaourt had that feature, that's interesting.
I like 'rebase -i' a lot, never thought of using that for groups. But well, if it's already in yaourt, why bother doing the same thing again in pacman ?
Yaourt doesn't have this feature for groups (sadly), but for -Syu. You can use the editor to select which packages you want to upgrade and with ones you want to ignore. I just meant you can do the same thing for groups, but it looks like my hint was to subtle ;) -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Wed, Oct 20, 2010 at 8:27 PM, Florian Pritz <bluewind@server-speed.net> wrote:
Yaourt doesn't have this feature for groups (sadly), but for -Syu. You can use the editor to select which packages you want to upgrade and with ones you want to ignore. I just meant you can do the same thing for groups, but it looks like my hint was to subtle ;)
Damn, sorry, I just cannot read these days. So why doesn't yaourt do it for groups, I would think the same code could be shared for both cases.
On 20/10/10 05:25, Xavier Chantry wrote:
One part of what's on http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working is about proposing a new interactive selection for installing groups. I did not like the old one, because I don't want to answer 50 questions when I install one group with 50 members. This is ugly, and the selection is not easily reproducible, for example you cannot easily copy/paste the answers of one run to another. I think a text frontend really sucks for this kind of workflow, a graphical or at least ncurses frontend would do much better.
But my new provision selection inspired to both Jakob and Dan that we could have the same for groups, so I went ahead and implemented it over the weekend.
$ pacman -S base-devel :: There are 11 members in group base-devel: :: Repository testing 1) make :: Repository core 2) autoconf 3) automake 4) bison 5) fakeroot 6) flex 7) gcc 8) libtool 9) m4 10) patch 11) pkg-config Which ones do you want to install? Enter a number (default=all):
Multiple choices are possible, separated by spaces. Either single number or a range a-b. Both single numbers and range can be negated with ^ prefix. Choices are applied successively, so each choice override previous ones (in case of conflict). If first choice is negative, all targets are implicitly selected, otherwise no target is implicitly selected.
Examples : 1) 3 6 8 : install automake, flex and libtool 2) 2-11 : install all targets in core repo 3) ^1 or 1-11 ^1 : install everything but make (like 2)) 4) ^2-11 : install everything but targets 2-11, i.e. only testing/make is left
No idea how practical / user-friendly it is, so feedback and testing welcome.
My general impression of this is that it is really, really good and a great improvement over what we have now or had in the past. Here are relatively minor comments: The "Enter a number" selection prompt is a bit weirdly worded when using e.g. "1-10 ^8". Maybe "Enter selection" instead? If the "selected 1" output is to stay (is it?), it should maybe say "selected <pkg>" instead? Also, using "1-10 ^8" says "selected 8... unselected 8". If that output is to say, I guess that should just say "unselected 8" maybe? Doing a "pacman -S base --needed" processes the --needed after the selection dialog which is annoying... is that easily changed? It does not matter if not. Allan
On Thu, Nov 4, 2010 at 10:53 AM, Allan McRae <allan@archlinux.org> wrote:
My general impression of this is that it is really, really good and a great improvement over what we have now or had in the past. Here are relatively minor comments:
The "Enter a number" selection prompt is a bit weirdly worded when using e.g. "1-10 ^8". Maybe "Enter selection" instead?
That sounds better.
If the "selected 1" output is to stay (is it?), it should maybe say "selected <pkg>" instead?
Also, using "1-10 ^8" says "selected 8... unselected 8". If that output is to say, I guess that should just say "unselected 8" maybe?
This was just meant to be a debug output for early testing / experimenting. I wanted to kill it if the idea was accepted.
Doing a "pacman -S base --needed" processes the --needed after the selection dialog which is annoying... is that easily changed? It does not matter if not.
Ah uhm right. Here is how it works now : 1) alpm_find_grp_pkgs gives to the frontend a list of sync packages, members of a specified group 2) interactive selection in frontend 3) alpm_add_pkg called on each package, where the --needed check is done (this means checking for existing local package and comparing versions) It's definitely possible to add needed check in the backend in 1) or in the frontend just before 2). Not sure where it would fit, I will let others decide that and I can then implement it if needed (no pun intended).
On 05/11/10 07:43, Xavier Chantry wrote:
On Thu, Nov 4, 2010 at 10:53 AM, Allan McRae<allan@archlinux.org> wrote:
My general impression of this is that it is really, really good and a great improvement over what we have now or had in the past. Here are relatively minor comments:
The "Enter a number" selection prompt is a bit weirdly worded when using e.g. "1-10 ^8". Maybe "Enter selection" instead?
That sounds better.
If the "selected 1" output is to stay (is it?), it should maybe say "selected<pkg>" instead?
Also, using "1-10 ^8" says "selected 8... unselected 8". If that output is to say, I guess that should just say "unselected 8" maybe?
This was just meant to be a debug output for early testing / experimenting. I wanted to kill it if the idea was accepted.
OK, that makes sense. You might want to keep it in the --debug output, at least until it is widely tested.
Doing a "pacman -S base --needed" processes the --needed after the selection dialog which is annoying... is that easily changed? It does not matter if not.
Ah uhm right. Here is how it works now : 1) alpm_find_grp_pkgs gives to the frontend a list of sync packages, members of a specified group 2) interactive selection in frontend 3) alpm_add_pkg called on each package, where the --needed check is done (this means checking for existing local package and comparing versions)
It's definitely possible to add needed check in the backend in 1) or in the frontend just before 2). Not sure where it would fit, I will let others decide that and I can then implement it if needed (no pun intended).
I am really torn between front and backend implementation of this... I think I am leaning towards backend. Allan
participants (4)
-
Allan McRae
-
Florian Pritz
-
Xavier
-
Xavier Chantry