On 3/30/07, Aaron Griffin wrote:

On 3/30/07, Andrew Fyfe 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

Scott Horowitz wrote:

On 3/30/07, Dan McGee 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

2007/3/31, Nagy Gabor :

...

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

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