Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13282 - [bash] add bash-completion optdepends

Attached to Project: Arch Linux
Opened by kongokris 2 (nut543) - Sunday, 15 February 2009, 00:00 GMT
Last edited by Aaron Griffin (phrakture) - Thursday, 10 December 2009, 19:31 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I just saw: http://bbs.archlinux.org/viewtopic.php?id=30205 and remembered how this was a source of confusion for me too when i started linux/archlinux.

be sure to add a little text, or maybe this is unavoidable? that explains the usefulness of it :)
This task depends upon

Closed by  Aaron Griffin (phrakture)
Thursday, 10 December 2009, 19:31 GMT
Reason for closing:  None
Additional comments about closing:  See last comment
Comment by Allan McRae (Allan) - Sunday, 15 February 2009, 09:56 GMT
This does not make sense to me. bash-completion depends on bash.
Comment by Greg (dolby) - Sunday, 15 February 2009, 11:43 GMT
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".
Comment by kongokris 2 (nut543) - Sunday, 15 February 2009, 14:31 GMT
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')"
Comment by Greg (dolby) - Sunday, 15 February 2009, 15:03 GMT
That would only make sense IF bash provided any /etc/bashcompletion.d/d files, but it doesnt..
Comment by kongokris 2 (nut543) - Sunday, 15 February 2009, 16:24 GMT
what are you talking about?? How would bash-completion NOT "offer increased functionality or other
features when installed"?
Comment by Greg (dolby) - Sunday, 15 February 2009, 16:52 GMT
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.
Comment by kongokris 2 (nut543) - Sunday, 15 February 2009, 17:25 GMT
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".
Comment by Alessandro Doro (adoroo) - Sunday, 15 February 2009, 18:19 GMT
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.
Comment by Aaron Griffin (phrakture) - Sunday, 15 February 2009, 19:53 GMT
Added in trunk, will be in next rebuild
Comment by Aaron Griffin (phrakture) - Sunday, 15 February 2009, 19:55 GMT
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.
Comment by Greg (dolby) - Sunday, 15 February 2009, 20:00 GMT
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..
Comment by Aaron Griffin (phrakture) - Sunday, 15 February 2009, 20:19 GMT
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?
Comment by Greg (dolby) - Sunday, 15 February 2009, 20:32 GMT
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.
Comment by Aaron Griffin (phrakture) - Sunday, 15 February 2009, 20:51 GMT
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"
Comment by Greg (dolby) - Sunday, 15 February 2009, 20:59 GMT
OK i was wrong.
Comment by Alessandro Doro (adoroo) - Sunday, 15 February 2009, 21:02 GMT
@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.
Comment by kongokris 2 (nut543) - Monday, 16 February 2009, 13:10 GMT
yeah. Do every archlinux TU & Dev now agree on what optdepends are for?
Comment by kongokris 2 (nut543) - Monday, 16 February 2009, 13:10 GMT
or any way to 'enforce' it i mean?
Comment by Greg (dolby) - Monday, 16 February 2009, 16:45 GMT
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?
Comment by Aaron Griffin (phrakture) - Monday, 16 February 2009, 16:47 GMT
@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
Comment by Alessandro Doro (adoroo) - Monday, 16 February 2009, 16:56 GMT
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...?
Comment by Aaron Griffin (phrakture) - Monday, 16 February 2009, 17:00 GMT
@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
Comment by Greg (dolby) - Monday, 16 February 2009, 17:32 GMT Comment by Greg (dolby) - Sunday, 22 February 2009, 05:08 GMT
Its not the first time a similar request has been made, in fact it has been requested again by the same person.  FS#9753 
Comment by kongokris 2 (nut543) - Sunday, 22 February 2009, 20:39 GMT
oops. had completely forgot about that one. however your comment about pacman installing tab-completion for itself has never held have it?
Comment by Greg (dolby) - Sunday, 22 February 2009, 23:17 GMT
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.
Comment by Paul Mattal (paul) - Sunday, 06 December 2009, 19:55 GMT
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.
Comment by Aaron Griffin (phrakture) - Thursday, 10 December 2009, 19:31 GMT
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

Loading...