On 9/21/07, Pierre Schmitz wrote:

Hi,

while working on php I realized that I really need something like "optionaldepends" in a PKGBUILD. I am not sure about the current status of this; the last time it was decided that we print some message to the user using the install scripts.

But I am not very happy with that kind of workaround. It would be much cleaner to have such support in makepkg/pacman itself. It would be enough if those are just information which the user can ask for if needed. Currently you have to grep through pacman.log to see those messages after you have installed a package.

It could be implemented the following way: PKGBUILD optionaldepends=('package':'optional description why you might want to \ isntall this optional package' \ 'next package') makepkg treat optionaldepends like makedepends pacman show optional packages and their (optional) description after install add a switch to show those information after the package is allready installed

As an example of how "userfriendly" our current solution is see

Yep, there's an FR for exactly this. I can't find the one I'm thinking of... but I did use the term "optdepends" - I think Roman used the term "suggests" Best i can find: http://bugs.archlinux.org/task/6626

I like the idea, but many users like the current no-interactive pacman (libalpm) behaviour; and asking user whether he wants to install optdepends (or select some of them to install) can lead huge number of questions. So I like the current method; but that would be nice, if we could easily list optdepends, indeed. A new list_optdepends function in install script may help, which can be called after package install on request, too. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

On 9/24/07, Pierre Schmitz wrote:

Am Samstag, 22. September 2007 11:39:56 schrieb Nagy Gabor:

...

I like the idea, but many users like the current no-interactive pacman (libalpm) behaviour; and asking user whether he wants to install optdepends (or select some of them to install) can lead huge number of questions. So I like the current method; but that would be nice, if we could easily list optdepends, indeed. A new list_optdepends function in install script may help, which can be called after package install on request, too. Bye, ngaba

Listing them would be enough. Should be quite easy to implement, won't it?

Listing them would certainly be helpful, but many pkgbuilds already echo optional deps in their .install file. I hear the sentiment of Nagy's email, but I think those users could easily be accommodated. For example, you could have something in the pacman.conf like OptDepends = Prompt, and a user who doesn't want to be prompted could comment it out. I could also imagine that when you do get prompted, there is a way to say "no to all" or "abort". Or, maybe pacman could list out all the optional depends in a list: 1. foo 2. bar 3. baz and then the user could type "1 2" if they wanted those two installed, or "A" for all. I don't know, this would be a quick way of seeing and specifying everything that I would like, but maybe not others :) Scott

On Mon, 24 Sep 2007 11:30:36 -0500 "Aaron Griffin" wrote:

On 9/24/07, Pierre Schmitz wrote:

...

Am Samstag, 22. September 2007 11:39:56 schrieb Nagy Gabor:

...

I like the idea, but many users like the current no-interactive pacman (libalpm) behaviour; and asking user whether he wants to install optdepends (or select some of them to install) can lead huge number of questions. So I like the current method; but that would be nice, if we could easily list optdepends, indeed. A new list_optdepends function in install script may help, which can be called after package install on request, too. Bye, ngaba

Listing them would be enough. Should be quite easy to implement, won't it?

I'm going to tackle this when I can. For *NOW* we're just going to list them in the -Qi output and do nothing with it.

Dan had the following suggestion: optdepends=('cvs:required for git-cvsimport' 'foo')

This way we can get rid of the "reasons" echoed in the install files and clean those up as well.

Once we have optional depends in place, we can start doing fancy things with it, but for now, this shouldn't be much extra code.

What do you guys think of the "dep:reason" syntax?

+1 - simple, straightforward, and since package names can't have colons (right? That's not permitted?) it leaves no room for ambiguity. -- Travis

Am Montag, 24. September 2007 18:30:36 schrieb Aaron Griffin:

Dan had the following suggestion: optdepends=('cvs:required for git-cvsimport' 'foo')

There are cases when you need more than one package to get a special functionality. So we would need something like: optdepends=('foo bar:required for foobar support') Of course we could also use a , instead of a space as delimiter here. Pierre -- archlinux.de

On 9/25/07, Dan McGee wrote:

On 9/25/07, Pierre Schmitz wrote:

...

Am Montag, 24. September 2007 18:30:36 schrieb Aaron Griffin:

...

Dan had the following suggestion: optdepends=('cvs:required for git-cvsimport' 'foo')

There are cases when you need more than one package to get a special functionality. So we would need something like:

optdepends=('foo bar:required for foobar support')

Of course we could also use a , instead of a space as delimiter here.

Pierre

Is this overly complicated, however? Parsing is a hell of a lot simpler in the original case. I know it seems weird, but:

optdepends=('foo:required for foobar support' 'bar:required for foobar support')

would get the job done too. How many packages exist that would have an extremely long list of optdepends with duplicate reasons? I know you shouldn't design implementation around constraints of the programming language, but in this case it just seems to make so much more sense to not complicate the syntax.

While I agree with Dan here, I already know of one package that would fit this bill. I think, for right now, lets stick with what Dan has above... for multiple packages we'll just list them a few times, we can mold the syntax later once it's already in place.