[pacman-dev] pacman PKGBUILD needs depends=(python)
Just installed arch to do some testing, went to run rankmirros as pacman suggests and no python, ooops. Python needs added to the depends list for pacman3. Andrew
On 3/30/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Just installed arch to do some testing, went to run rankmirros as pacman suggests and no python, ooops. Python needs added to the depends list for pacman3.
Hmmm, we can't really do that. It's also more of an optional depend anyway, so we should add it to the install message.
On 3/30/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/30/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Just installed arch to do some testing, went to run rankmirros as pacman suggests and no python, ooops. Python needs added to the depends list for pacman3.
Hmmm, we can't really do that. It's also more of an optional depend anyway, so we should add it to the install message.
Yeah, that might be a good thing to add. On a side note, what do you guys think about "optdepends"? <http://bugs.archlinux.org/task/6626> If we pick a name now, we can worry about implementation details later. But it would be interesting to have this kind of thing. I did find, way back in Flyspray, a request for this same kind of thing that was closed by Judd because he thought it was unnecessary. I feel like things may have changed enough since then, but I don't know for sure. -Dan
On 3/30/07, Dan McGee <dpmcgee@gmail.com> wrote:
On a side note, what do you guys think about "optdepends"? <http://bugs.archlinux.org/task/6626>
If we pick a name now, we can worry about implementation details later. But it would be interesting to have this kind of thing. I did find, way back in Flyspray, a request for this same kind of thing that was closed by Judd because he thought it was unnecessary. I feel like things may have changed enough since then, but I don't know for sure.
I personally dislike optdepends because it doesn't make sense to me. If something is optional, it's not a dependency; if it's a dependency, it's not optional. I'd go with either "optional" or, as mentioned in FS, "suggests". But everyone is going to have an opinion ;-) I think every user would appreciate this feature implemented, the name is less important. Scott
Scott Horowitz wrote:
On 3/30/07, Dan McGee <dpmcgee@gmail.com> wrote:
On a side note, what do you guys think about "optdepends"? <http://bugs.archlinux.org/task/6626>
If we pick a name now, we can worry about implementation details later. But it would be interesting to have this kind of thing. I did find, way back in Flyspray, a request for this same kind of thing that was closed by Judd because he thought it was unnecessary. I feel like things may have changed enough since then, but I don't know for sure.
I personally dislike optdepends because it doesn't make sense to me. If something is optional, it's not a dependency; if it's a dependency, it's not optional. I'd go with either "optional" or, as mentioned in FS, "suggests".
But everyone is going to have an opinion ;-) I think every user would appreciate this feature implemented, the name is less important.
Scott
'suggests' would be my preference, because pacman will suggest you install the packages :) my opinion on the ideas in FS#6626... ranking - no list during install - yes option to install - probably, I like Roman Kyrylych's suggestion (http://bugs.archlinux.org/task/4845#comment10357) Andrew
On a side note, what do you guys think about "optdepends"? I like the idea, the name is not so important. However, it doesn't help too much without a description (because optdepend=python isn't very informative: I'd like to know what are the extra features). And optdepends should be store in db or not? Because if not, optdepend can be easily removed after -Qe; or the optdepend can be broken after -S. And probably there are more complicated cases, where user's interaction needed to decide whether keep optdepend or not. Again, I like the idea, but it's not so easy to implement.
Bye, Nagy Gabor
2007/3/31, Nagy Gabor <ngaba@petra.hos.u-szeged.hu>:
On a side note, what do you guys think about "optdepends"? I like the idea, the name is not so important. However, it doesn't help too much without a description (because optdepend=python isn't very informative: I'd like to know what are the extra features). And optdepends should be store in db or not? Because if not, optdepend can be easily removed after -Qe; or the optdepend can be broken after -S. And probably there are more complicated cases, where user's interaction needed to decide whether keep optdepend or not. Again, I like the idea, but it's not so easy to implement.
Database should track "optional dependencies" too. (yep, I don't like "dependency" word for optional things, I prefer "uses=(...)" notation) AFAIR an implementation with descripion was proposed on this ML, like: uses=(python-libnotify:"support for system tray popups" ...) I'd like to point a more serious issue: how to select those additional packages ("optional dependencies") for download during, i.e. pacman -S gnome? Two choices: 1) ask user for every such package _before_download_ - then description of each optional package should be displayed at this time (which requires storing them in PKGBUILDs and repo DB) 2) ask user for every such package right after installation of package that makes use of them - then description of each optional package should be stored and displayed in post_install of package that uses it. I strongly prefer the second choice. It's much simpler and doesn't differ much from the current way of installing optional packages. Then we'll have this: 1) pacman -S gnome (or any other group or big package with many depends) (optional) pacman asks for each package in group 2) pacman lists all packages that are going to be installed 3) pacman installs those packages, displaying post_install messages if they exist, i.e.: installing foobar... :: foobar can make use of following packages if present: :: python-libnotify - systray popups support :: libfoo - blah-blah-blah 4) pacman notices uses=(python-libnotify libfoo) in package info and prints: Install python-libnotify [y/N]? y Install libfoo [y/N]? 5) now installation of package is fully finished, pacman writes to local db entry: %USES% python-libnotify !libfoo so it knows that python-libnotify was selected by user and libfoo wasn't. There's one more important point: when python-libnotify was already installed before foobar, then pacman should print: python-libnotify: already installed and think about it like it was user's choice And about uninstalling: pacman should warn user when he/she wants to uninstall python-libnotify: The following packages make use of python notify: foobar Uninstalling it may disable some functionality in those packages. Proceed with uninstall [y/N]? I think all issues will be thought out thhoroughly during early stages of implementation. -- Roman Kyrylych (Роман Кирилич)
I strongly prefer the second choice. It's much simpler and doesn't differ much from the current way of installing optional packages. Then we'll have this: 1) pacman -S gnome (or any other group or big package with many depends) (optional) pacman asks for each package in group 2) pacman lists all packages that are going to be installed 3) pacman installs those packages, displaying post_install messages if they exist, i.e.: installing foobar... :: foobar can make use of following packages if present: :: python-libnotify - systray popups support :: libfoo - blah-blah-blah 4) pacman notices uses=(python-libnotify libfoo) in package info and prints: Install python-libnotify [y/N]? y Install libfoo [y/N]? 5) now installation of package is fully finished, pacman writes to local db entry: %USES% python-libnotify !libfoo so it knows that python-libnotify was selected by user and libfoo wasn't.
Be careful with this one. One of the reasons Judd preferred pacman's methods over dpkg is because it doesn't ask you anything after it starts downloading. I wasn't so sold on the idea when I first moved over to Arch, but I now prefer non-interactive updates to interactive ones. If I walk away after I've said the last 'y' to start downloading, I know that the install will probably be done when I get back. Using something like dpkg, I may have installed only one package and have to wait longer. Prompting during install: -1 Jason
Prompting during install: -1
-1 too. But I have no idea how to solve multiple providers problem: How should pacman figure out which package is going to be installed after "pacman -S provided_foo"? Any idea? So let me make a compromise: There should be an option to force pacman decide instead of us. Back to the optdepends question: Install all/no optdepends option. Or ask the user _before_ downloading, see replaces & conflicts... Bye, ngaba
2007/4/2, Jason Chu <jason@archlinux.org>:
I strongly prefer the second choice. It's much simpler and doesn't differ much from the current way of installing optional packages. Then we'll have this: 1) pacman -S gnome (or any other group or big package with many depends) (optional) pacman asks for each package in group 2) pacman lists all packages that are going to be installed 3) pacman installs those packages, displaying post_install messages if they exist, i.e.: installing foobar... :: foobar can make use of following packages if present: :: python-libnotify - systray popups support :: libfoo - blah-blah-blah 4) pacman notices uses=(python-libnotify libfoo) in package info and prints: Install python-libnotify [y/N]? y Install libfoo [y/N]? 5) now installation of package is fully finished, pacman writes to local db entry: %USES% python-libnotify !libfoo so it knows that python-libnotify was selected by user and libfoo wasn't.
Be careful with this one. One of the reasons Judd preferred pacman's methods over dpkg is because it doesn't ask you anything after it starts downloading.
I wasn't so sold on the idea when I first moved over to Arch, but I now prefer non-interactive updates to interactive ones. If I walk away after I've said the last 'y' to start downloading, I know that the install will probably be done when I get back. Using something like dpkg, I may have installed only one package and have to wait longer.
Prompting during install: -1
I understand you and I didn't say it will be non-optional behaviour. I think something like AskForOptionalDependencies = 1 / 0 in pacman.conf will be OK. It can even be disabled by default. Then users won't see any change from current behaviour - there still will be post_install messages about optional components, and there will be still no questions from pacman. That's why I proposed this scheme as it allows to not change installation/upgrade process much, it's just allows to handle manual installation of optional packages with pacman. -- Roman Kyrylych (Роман Кирилич)
participants (7)
-
Aaron Griffin
-
Andrew Fyfe
-
Dan McGee
-
Jason Chu
-
Nagy Gabor
-
Roman Kyrylych
-
Scott Horowitz