Arch Linux

This does not make sense to me. bash-completion depends on bash.

This is not the way dependencies work in Arch Linux (even optdepends). Gnome doesnt depend on xorg, ncmpc doesnt depend on mpd. You are expected to "know what you are doing".

it probably was a bad explanation. The only thing i'm saying is that bash-completion isn't listed as an optdepend in the bash package. Isn't bash-completion an optdepends?

Then i tried to explain that a text like:

optdepends=('bash-completion: introduces <TAB> completion for a number of cmdline programs, including pacman')

would be useful.

From the PKGBUILD manpage:
"optdepends (array)
An array of optional packages (and accompanying reasons) that are not essential to the package, but would offer increased functionality or other
features when installed. optdepends are currently for informational purposes only and are not utilized by pacman during dependency resolution. The
format should be similar to the following:

optdepends=('fakeroot: for makepkg usage as normal user')"

That would only make sense IF bash provided any /etc/bashcompletion.d/d files, but it doesnt..

what are you talking about?? How would bash-completion NOT "offer increased functionality or other
features when installed"?

Thats exactly what my first reply was about. "This is not the way dependencies work in Arch Linux (even optdepends). Gnome doesnt depend on xorg, ncmpc doesnt depend on mpd. You are expected to "know what you are doing"."
The way optdepends work in Arch until today, for something to be an optdepend, it has to needed by some feature of the original package, in this case bash. But bash-completion doesnt do that.

I have no idea what the current policy is concerning optdepends, nor can i make sense out of what you are saying(no pun intended). However according to the PKGBUILD _manpage_, adding bash-completion as an optdepend doesn't seem to be wrong, and if the point of optdepends is to make it easier for users to discover related packages which "may be of some use" <- this is obviously subjective, but unavoidable in the word "opt".

this seems more correct than "for something to be an optdepend, it has to needed by some feature of the original package"<- which seems to me to be a description of the depends array because if i download a program i damn well want to use all it's features! and not have it decided for me by some decision of the packager concerning what features "i might use".

Let's see how thing works at the moment.
A package (pacman for example) provides its own completion script. It cannot work if bash-completion isn't installed because:
1) the script is sourced by /etc/bash_completion
2) the script fails if sourced in absence of /etc/bash_completion

$ . /etc/bash_completion.d/pacman
-bash: /etc/bash_completion.d/pacman: line 149: syntax error near unexpected token `('
-bash: /etc/bash_completion.d/pacman: line 149: ` -@(U|R|S|Q|h|V))'

Technically bash_completion shoud be an optdepend of the package (pacman in this case).
Bash completion feature doens't require the bash-completion package in order to function properly, so "technically" bash-completion isn't necessarily a bash optdepend; but this depends, sorry for the word playing, very much by the package mantainer feelings.

Added in trunk, will be in next rebuild

Wow, I didn't see all these comments. I think this makes sense, if you ask me. bash-completion increases the funcationality of bash. Maybe optdepends is a poor name, but we use optdepends for "plugins" of many different apps - bash-completion certainly fits the "plugin" idea.

Doesnt xorg increase the functionality of gnome, kde, xfce or every window manager out there? Same for mpd & all its frontends and thousands of other packages i could name.
Some other examples: Pacman provides /etc/bashcompletion.d/pacman and _pacman for zsh completion. Does that mean pacman should optdepend on bach-completion and zsh? Same for GNU screen. It provides a screen zsh completion..

I don't understand why this is such a huge deal. I am 100% positive we can find a case where "foobar-plugin" depends on "foobar" yet "foobar-plugin" is an optdepend as well.

optdepends, as far as I know, were created to get rid of the "install blah for some functionality" type messages, correct? That is *exactly* what is happening here. No one would think the logic was wrong if I added an install message that said "Install bash-completion for better completion", and then people would complain (the exact same people complaining here, most likely) that this should be an optdepend.

Are you guys seriously suggesting that this be done via an install message?

I dont think its a big deal regarding bash and its completion. Its a big deal in general. Anyway, i am not an optdepends fan. Maybe i will make a seperate bug report for them if i think its appropriate.
On topic: Like i said before, optdepends were treated differently until this point. This is revolutionary because a totally unrelated package to bash, is included as a dependency to it, without being a dependency for one the features bash provides. I might be wrong but this is the first time it will happen.

Some examples of the exact same situation:

- core/kernel26/PKGBUILD:optdepends=('crda: to set the correct wireless channels of your country')
Obviously has nothing to do with the kernel nor anything the kernel runs. It is a userspace app

- core/syslog-ng/PKGBUILD:optdepends=('logrotate')
Totally unrelated. Deals with the output files of syslog not the functionality of the app

- core/openssl/PKGBUILD:optdepends=('ca-certificates')
Similar "enhancement" to bash-completion - additional files that the original package may use

- extra/swfdec/PKGBUILD:optdepends=('gstreamer0.10-base: required for various audio and video formats'
swfdec may depend on gstreamer, but the gstreamer plugins have NOTHING to do with swfdec - see quodlibet for a more extreme case

- extra/octave/PKGBUILD:optdepends=('texinfo: for help-support in octave'
This one is fairly obvious. Not an extension to the app but something totally unrelated to view files in the package

- testing/kdebase-workspace/PKGBUILD:optdepends=('kdebindings: plasma scriptengine for Python')
optional language bindings have nothing to do with the functionality of this...

There's many many many more - this is not a "first"

OK i was wrong.

@adoroo: Bash completion feature doens't require the bash-completion package in order to function properly, so "technically" bash-completion isn't necessarily a bash optdepend.

I quoted "technically" to unveil the semantic problem caused by the word "functionality".
It should more stressed that optdepends "are currently for informational purposes only" (PKGBUILD(5)).
Take it as a unlucky synonym of "suggestedpackages", not as a half-dependency!

Many distributions install bash-completions by default. New linux users coming from other distributions not necessarily know that the useful completions aren't black magic and comes from a separate package.

yeah. Do every archlinux TU & Dev now agree on what optdepends are for?

or any way to 'enforce' it i mean?

The only "problem" I have with this is: While as i already said twice above, gnome doesnt depend on xorg, not even optdepend (read above for more examples than gnome),
meaning stuff the application NEEDS in order to operate, not just "extend the functionality" are not listed as dependencies, then comes along something like optdepends
which suggests installing bash-completion for bash (just an example).
This doesnt make any sense to me, and from my point of view its an inconsistency. If bash optdepends on bash-completion, can someone tell me what is xorg for gnome?

@dolby: I'm not sure of the original decision for xorg/gnome, but why does that impact THIS report? Everything we do is not some grandiose scheme that's all interrelated with everything else we've done - they're isolated incidents. The an page is very clear on what an optdepend is for. This case obviously fits that. It is totally unrelated to xorg and gnome - for that I would recommend we talk to the gnome and/or xorg maintainer, and file a bug report about it. But it has no impact on THIS bug

xorg/gnome
If I remember well the decision was based on the fact the X server and clients can be different machines.
IMO this can justify xorg not being a gnome dependency; but what about optdepends...?

@adoroo: That sounds right. Also the fact that there are technically may more X servers than just xorg.
I would agree that adding the X server as an optdepend would be a good idea - dolby, would you mind filing a bug report for that so I can close this one? This bug is implemented

 FS#13306 

Its not the first time a similar request has been made, in fact it has been requested again by the same person.  FS#9753 

oops. had completely forgot about that one. however your comment about pacman installing tab-completion for itself has never held have it?

Yes, i seem to be under the impression that bash completion works like the zsh one in my comment for some reason. I cant explain it otherwise.
Thats not why i posted the link though. I did that first of all to note that this is not the first time you have requested this, but more importantly that only a year ago,
feature requests like this one, werent even considered worth being assigned to the maintainer of the package. They were just closed with wont implement.

So this was added:

http://repos.archlinux.org/wsvn/packages/bash/trunk/PKGBUILD?rev=27005

Then removed:

http://repos.archlinux.org/wsvn/packages/bash/trunk/PKGBUILD?rev=42659

Let's say if nobody says "hold it" before January bug day, I think we should just close this as "won't implement". Though I think I agree with Aaron that the optdepend makes sense, practically speaking, here.

Yeah, I added it and got yelled at. It's funny how the biggest stinks are raised by the tiniest issues, but no one cares when we start adding crazy patches to the kernel or xorg. Bikeshedding at it's finest.

I'll close this now