Arch Linux

Adding some people concerned

To be clear: No matter what anyone else says, optdepends were added because install scripts outputting "install this for blah support" were getting annoying. We can get all philosophical about what "optional" and "depend" mean, but that's the long and short of it.

ncmpc,mpc,sonata <-- i believe these support the mpd core running on a different machine? I don't know why all of those wm's doesn't depend on xorg-server. It seems like a bug.

@nut543: That's most likely the same reason for X too.

Looks like mpd front ends and WMs should probably optdepend on mpd / X with something like "for running on the local machine" or similar. Would that cover this discrepancy?

Some examples you made:
- core/openssl -> ca-certificates: ca-certificates was part of openssl, which changed for some reason. Because ca-certificates needs openssl to process the certificates, there was a dependency loop. This loop is broken by making it an optdepend.
- core/syslog-ng -> logrotate: this used to be a dependency in the past I think, but as rotating logs is optional, it was made an optdepend. Both packages are in core/base anyways, so I don't even think users will install syslog without logrotate.
- core/kernel26 -> crda: the wireless domain used to be set unrestricted from the kernel. This is now limited to a few channels by default and should be configured using crda. This optdepend was added because it gives a hint to people why their wireless network isn't working anymore after a kernel upgrade to 2.6.28.

Then there's bash with bash-completion: I'm actually against this optdepend. Though bash-completion extends bash with optional functionality, what will be the next optdepend for bash that extends its functionality? Shall we add coreutils as optdepend to bash because you can execute nice coreutils commands from a bash shell?

IMHO optdepends should only be used to suggest a dependency which is an optional dependency not needed for core functionality which is part of the package itself. An example of this is gnome-power-manager that has gnome-panel as optdepend. It's a gnome application, with a gnome panel applet. I changed gnome-panel into an optdepend so XFCE users didn't have to install half of the GNOME desktop if they want to use gnome-power-manager.

If we start adding optdepends for functionality that is not included in the package but is provided by the external package, then it shouldn't be an optdepend. What's next? adding gnome-applets optdepends to gnome-panel because it could be nice to have some applets on your panel. The applets extend the functionality of gnome-panel, but they have nothing to do with the gnome-panel package itself.

Change the meaning of optdepends in the manpage then, and reintroduce the tedius install messages. The rest of us would like to have an optdepend who means just that, optional dependency - not needed for program running but which introduces functionality which may be nice. Now, i know that that is subjective, and so every packager would be free to interpret that as needed, and we are allowed to stay within reason and not have to introduce optdepends in the bash PKGBUILD for every shell utility out there. For such practical functionality as <tab> completion in bash however, it would be "a nice thing to have"TM.

just to clarify. I do not believe that it is of terrible importance to have an optdepend for every package out there "which may be of some use" to another(because it would add to much overhead for the packager(?) and i do agree with gregorius on "people/users are supposed to know what they are doing"). However, for cases like bash's bash-completion optdepend i see no problem, because it's such a widespread "problem".

Actually, Jan, based on the wording of the man page, the gnome-applets example you give fits perfectly.

To take a step back here: my understanding of optdepends is exactly as it's described in the man page. optdepends are "nice-to-haves" that work with the package in question. In this case, bash-completion is a "nice-to-have" for bash. This fits with the current phrasing and my current understanding.

But again, let's look at it this way: no one would argue that bash-completion compliments bash, right? If I wanted to inform users of bash completion, should I use an install scriptlet? Isn't this the _exact_ reason optdepends were added? No one has answered this question of mine yet. Would all of you harping AGAINST this as an optdepend be comfortable with it in an install script?

We have two camps here:
* Those who feel optdepends are purely informational - a way to inform people of related and useful packages
* Those who feel optdepends are for things only the original app can "load" in some way - dlopen or plugins and the like.

Is this correct?

Yes correct.
I agree with Jan. There should be a somewhat standard behaviour to this, just like all other packaging related stuff.
I dont like the post install msg for the same reason i dont like the optdepend.
Correct me if im wrong but post install messages didnt do what you are saying they did and would be "reintroduced" either.

Well, the original request is "inform users that the completion they expect from other distros and the like is actually a separate package" and I agree that we should inform the users of this. If we're going to disagree that this should be an optdepend, then adding it as a post-install/upgrade message is the only other route, unless you have another idea

I dont have another idea. The original request should IMO have been denied because bash-completion isnt included in bash on other distros and because its not the default.
In fact i dont think its even included in bash anywhere. Not even in Ubuntu. Its just installed by default.
I understand that you are trying to implement dpkg's "recommends" and "suggests" function, in one in pacman.
But see for example what dpkg recommends (in green) for git: http://packages.debian.org/experimental/git-core and what pacman does: http://repos.archlinux.org/viewvc.cgi/git/repos/extra-i686/PKGBUILD?view=markup
I dont like the first one. I already explained what MY idea of optdepends is. Like i said before, there should be some standard. Thats the only thing i consider needed.

Maybe that's the discrepancy here: I am thinking of optdepends as BOTH "recommends" and "suggests", whereas Camp#2 is thinking of it as just... erm "suggests" (I may have that wrong).

There is a difference of opinion here and we're not going to convince the other side that one is the best. So, how do we solve this? Ask the pacman guys? Have the devs vote on it?

i have no idea what suggests means for dpkg. But bash-completion is recommended for bash.
If you dont know, maybe Dan could shed some light.

I have no idea what camp 2 wants. I still haven't been able to make sense out of what they propose.

Interesting conversation.

I suppose I fall into camp 2, but it seems a bit of a false dichotomy to me. Both seem a bit 'dirty'..Either you have echo statements all over in install files, or you have an oddly named 'dependency' feature that doesn't quite fit a mental model.

But! To me at least, it is simply a problem of wording. I read 'optdepends' and instantly think of something being required. I imagine module loading, and such. git is an example that instantly springs to mind. The relationship with git and git-svn, etc.

Now.. I can be a bit of a pedantic prick when it comes to vernacular, because I think the relation of words to concepts can be very important and powerful.

So this isn't really a problem for me based on the manpage, and the usage. It is just a problem with the wording of the thing itself. If it was called 'morefeaturespewpewpew' then I would never have through more than twice about it (and in all honestly, I barely did as it is!).

Maybe changing the name of it from 'optdepends', of which 'depends' is kind of a loaded term, to 'optpackages' would be a nice middle ground. Thereby making it clear that it isn't what people would normally associate this kind of thing with. It is simply a way to get more features with related packages. Not that they require the original package to function, or are necessarily based on module loading an an API.

i support this initiative! but i would suggest subjdepends inplace of optdepends or optpackages. Then it would be no doubt it would be a /subjective/ decision by the packager and not terribly important.

Who's gonna guarantee not having optdepends like these though: http://packages.debian.org/sid/ratpoison (see green diamonds and blue squares). Unless this is the wanted behaviour from pacman, thus optdepends were introduced.
And just a note on what i agreed without any second thought above:
"We have two camps here:
* Those who feel optdepends are purely informational - a way to inform people of related and useful packages"
Yes but, since there is no definition (how could there) to what is a related and useful package exists, IMO its better not having them at all.

Seriously, how did this get so out of hand?

I look at the "panic case" of ratpoison in debian and you know the first thought that comes to mind? "So what?"

So what? Do you know what an optdepend does? It outputs text. To a terminal screen. That's it. That's all we're talking about here. Output.

The definition is "a way to inform people of related and useful packages". The interpretation of what is "useful" however is subjective. However in most cases it should be pretty straightforward. I mean, i'm sure 95% of people would agree: bash-completion is useful for bash, so we add it as an optdepend.

I personally can't understand the difference betweens debians "recommended" and "suggests". (see: packages.debian.org/sid/ratpoison). "so the packager "recommends" some packages and "suggests" someone else... WTF!?" I do _NOT_ think archlinux would benefit from a similar "solution" which seems like someone did a brainfart. (just like the overly complex "seperate every package into a gazillion more" debian policy)

I would say bash-completion should never be a optdepend of bash. That seems like a slippery slope similar to the examples Jan brought up- it is not in our best interest, and all the sudden a simple install of a few packages will spit out 80 more that you might like. We've now lost the benefit.

When I originally said "maybe we should do optdepends" in pacman, I saw them as optional *dependencies*, not suggested packages. For something like GIT, the package will run fine without some of the perl modules needed for git-svn, and a lot of people will never need these things, so it is nice to make them optional instead of required. On the other hand, I didn't pepper my optdepends array with things like tig, xinetd, and qgit (all of which could be seen as helpful to have when using git).

Maybe the man page documentation is misleading, but it comes down to this for me: if we were still in the pacman 2.9.8 days, when optdepends didn't exist, then most, if not all of the things in the optdepends array should instead be in the depends array (rather than completely omitted). So I'm in camp #2.

i still have yet to see anyone produce a definition of optdepends that goes for all cases AND makes sense if the definition in the manpage is not agreed upon. How can we have this discussion if it's just one big cloud of emotion?

Dan and I talked about the rewording over jabber. He's the final authority on what pacman does here, so if he says "whoops, that's because my wording was bad" then he's right.

We/he is going to fix it so there's no disparity here.

ok. then we should also get an array for something we can use to INFORM users about relevant packages to them then unless everyone is a-ok with using install files. I'm personally not, becase it looks ugly and demands more work by _ME_ and i STILL haven't gotten a definition of optdepends that is actually applicable. You know, as in possible to /apply/ to a large set of sets in Real LifeTM, and that applies all the time to those large sets thus making it a Logical RuleTM.

Yeah, I'll probably just add an install message to bash that points to the bash-completion package for more advanced completion in this case.

The wording will be fixed by the pacman devs - it is enough for them to know that there is confusion, and they will fix it. It'd be silly to toss wording around in this thread, as it's not all that solution oriented right now.

For some small amount of clarity, I said the following to Dan:
>>>
hmmm "any and all packages not needed for normal functionality but needed to make full use of the package" or some such
"full use of all files in this package" ?
that covers things like texinfo as an optdepend
<<<

I don't know what the final wording will be, and frankly I don't care - as long as this is cleared up, I'm happy

Any outcome on this one? are we expected to go back to using install files to inform users about useful packages/additional functionality? As a sidenote, *most* people are using optdepends in this way, and perhaps it is unneeded to say, I also find this the most logical.

Yeah, I thought I informed you of the outcome already.
a) Dan is the authority on pacman. He said "it's supposed to be this way" and thus it is so
b) The wording needs changing - this will take time to get into a pacman release

Dan?

 FS#13395  is another example, of what you see as a need, is not happening.
"All the cool kids do it" doesnt count if the cool kids are me and nut543.
And just for the record, since i wasnt the one who first brought up the "people coming from other distros expect this and that", see what debian does: http://packages.debian.org/sid/openoffice.org green dots again "recommends".

i'm sorry dolby, i don't understand what you are saying.. no pun intended, but can you try to be a bit clearer?

You said: "*most* people are using optdepends in this way".
I gave you an example where your argument fails. Most (if not all) developers dont use it that way.
Note that openoffice doesnt even have a post install message about installing some kind of font in order to have text in the menu, which most people would claim is core functionality for openoffice and not optional like your request with bash. The developer, AndyRTR in this case, just tells the one who made the report to install some font.
If what you refer to as most, doesnt include the Arch developers, your argument is totally irrelevant to what this bug report is about.

The font issue is a bit silly - I imagine lots of apps would break if you don't install any fonts. At least OOo doesn't crash :)

I agree with the last line dolby wrote: If you're only talking about AUR/community packages when you say "most people use it this way", it's not exactly a compelling argument

http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=48b209d6121f24e990951daf0edf1345012b4c78

I should have stopped reading this on the first comment from Aaron :

""To be clear: No matter what anyone else says, optdepends were added because install scripts outputting "install this for blah support" were getting annoying. We can get all philosophical about what "optional" and "depend" mean, but that's the long and short of it.""

I thought Dan agreed with that. I personally think the word "optdepends" is not important, and I don't think the man page needs to give it a precise meaning.
There are two parts in the description :

1) an interpretation of what optdepends mean
""An array of packages (and accompanying reasons) that are not essential for
base functionality, but may be necessary to make full use of the contents
of this package.""

2) how is optdepends actually used by pacman
""optdepends are currently for informational purposes only
and are not utilized by pacman during dependency resolution. The format
should be similar to the following:""

Imo only 2) is really important there and 1) could be dropped. It's up to the distribution using pacman to decide how to use it.

I agree. And thanks for pointing it out. I am sorry if that wasnt clear from the description of this report, but the inconsistency i am talking about is ireelevant to pacman.
I am only talking about how optdepends are used in Arch. The fact that i added this part of man PKGBUILD(5) only has to do with the fact that nut543 who opened the feature request
based his request on that part of text.

One thing I would like to point out is this "optdepends are currently for informational purposes only". Note the "currently" in there. One day I would really like to be able to have optdepends recognised as needed by a packages for dealing with orphans. Hence my negative comment for  FS#13282 .

e.g. python has tk as an optdepened.
> pacman -S python
> pacman -Qi python
Optional Deps : tk: for IDLE, pynche and modulator

> pacman -S --asdep tk
> pacman -Qi python
Optional Deps : tk: for IDLE, pynche and modulator (installed)

> pacman -Qqtd
> pacman -Qqtd --optdep
tk (optdepend for python)

Given that is not what optdepends were initially designed for, I guess I will have some convincing of Dan to do...

I just read this all again... Bug reports should be automatically closed after 10 comments! :)

So, does this all just come down to
1) how optdepends are handled by pacman.
or
2) a way of informing users of "recommended" additions to a package.

#1 makes this a dupe of  FS#12708 . #2 (to me) seems that we are assuming users are too stupid to find packages finding functionality they want.

Hence, I am happy if this gets closed...

I agree with what Allan said on #2, but IMO you (devs) agree on how optdepends should be used.
As i said before, this isnt about pacman, so #1 is irrelevant. This shouldnt have moved here.

Closing as "Not a bug". File a bug for specific concerns about incorrect optdepends.