Arch Linux

Hi, I think you don't understand what optdepends are for. From the wiki:

"An array of package names that are not needed for the software to function but provides additional features. A short description of what each package provides should also be noted."

liteide is a package that is not needed, but provides additional features (editing and building projects written in Go).

All the optdepends has a short description of what each of them provides.

Stop filing bug-reports with subjective ramblings like "descriptions are useless", especially when the descriptions are not useless and actually follows the little documentation we have on the topic.

I will add bzr and svn to the list as well.

Why is the language that the VCS is written is appropriate for describing the package as a optdepend of Go?

"A short description of what each package provides should also be noted."

This seems pretty clear to me. Using an implementation detail of the optdepend has little bearing on why I would choose to install it to support the go package.

I opened this as a direct result of a conversation from IRC in #archlinux-dev where another developer had absolutely no idea why git and hg were marked as optdepends. It was only because I have some aging familiarity with go that I knew the 'go' binary would call out to an external binary to fetch source repos.

I really don't appreciate your tone.

The previous descriptions of the optdepends *did* note what each package provided. The language the version control system was implemented in was also included. One of the few features that differs in the short descriptions of the version control systems, are which languages they are written in. If you look at the package descriptions, they all sound pretty similar, stating to be distributed/fast/scalable/decentralized version/revision control systems. No arguments for why anyone should install them there.

"Why you should choose to install an optional dependency" is a very subjective requirement for the optional dependency description that I don't think you have thought trough. Everybody will have different reasons for why they would want to install an optional dependency. Also, just because you have written about the topic in a closed IRC channel and are opinionated, does not make you in the right.

"I really don't appreciate your tone" is a complete departure from the subject and hand, and also quite laughable, coming from you.

Optional dependencies enable *features* in the package. The optdepends array should describe what features a given dependency enables. There is nothing subjective about that.

When you argue in bad faith to avoid recognizing that you were mistaken, you are being a drag to the developers and trusted users team, if not the entire Arch community. Unless you stop this behavior, your packager rights will have to be revised.

> The previous descriptions of the optdepends *did* note what each package provided.
What was your impetus to change this?

> Everybody will have different reasons for why they would want to install an optional dependency.
This is where we disagree. You'd install the "git" package with "go" because you want "go get" to be able to fetch a git repo. You'd install "hg" because you want "go get" to be able to fetch a mercurial repo. Can you elaborate on why you think this is subjective?

Lots of other packages follow this idea of explaining the relationship between a package and its optdepends:

- linux
crda: to set the correct wireless channels of your country

- pacman
fakeroot: for makepkg usage as normal user

- opal
ffmpeg: h263 and mpeg4 plugins

- apr-util
gdbm: enable gdbm support
libldap: enable ldap support
unixodbc: enable odbc support
libmariadbclient: enable mysql/mariadb support
postgresql-client: enable postgres support
db: enable berkley db support
sqlite: enable sqlite support
nss: enable nss crypto support
openssl: enable openssl crypto support

- aisleriot:
libkdegames: KDE card sets
pysolfc: PySol card set
pysolfc-cardsets: PySol card sets

- akonadi:
postgresql: PostgreSQL backend

- alsa-lib:
python2: for python smixer plugin

> "I really don't appreciate your tone" is a complete departure from the subject and hand, and also quite laughable, coming from you.
So, you're allowed to continue to attack me for, what seems to be, usage of a term in the bug title that you disagree with, and I'm just supposed to accept it. I've been civil -- I ask that you do the same.

Yes, we disagree on this one. Even though some packages has the type of descriptions that you prefer, it's still just a preference.

However, I changed the descriptions for the optdeps to be closer to the package description for the respective packages.

I disagree that I have attacked you and I disagree that you have been civil.

If there is some sort of consensus (or documentation) that indicates that optdeps should have a different description than for this package, I will change it, of course. But until then, I'm closing this (again) as not a bug.

You haven't addressed anything material in this bug report -- you only seem interested in playing with the bug metadata and avoiding answering any of the questions posed here. That you disagree is fine -- you've yet to explain why you disagree.

What is your reasoning for duplicating package descriptions in optional dependencies? What value does this provide to end users? I'm interested to hear your perspective so that we can update the wiki and remove any potential ambiguity.

Lets look at the optdepends:

liteide - that is not a dependency at all. It is like listing gcc as an optdep for bash because you might want to compile something in the shell.

mercurial: scalable distributed SCM tool. - this provides me no information on what this is used for in go and why I would like to install this as a dependency. The old description "mercurial: VCS written in Python" is every bit as bad.

How about something like: "mercurial: for the mercurial VCS management extension" (I don't know go, so that could be wrong terminology).

luarocks has similar optional dependencies:

* cvs: for fetching sources from CVS repositories
* git: for fetching sources from git repositories
* mercurial: for fetching sources from mercurial repositories

The descriptions could even be reused from there as-is.

Dave, a bug report is not a Q/A session. This is clearly not a bug, but a matter of preference. If you wish to discuss policies concerning optdepends, take it to the forum or a mailinglist.

Allan, I agree that liteide may not belong as an optdep (however helpful to new users of the Go programming language). I can remove it.

Daniel,

I don't think it brings any clarity to state that "cvs is for fetching sources from CVS repositories", "git is for fetching sources from git repositories" etc. All version control systems are for fetching sources from repositories. We should expect users to know what version control systems are. If they don't, I think the optdepends array is a peculiar place to attempt to explain it to them.

You can modify it to explain why Go is depending on it - it uses Git to fetch remote packages from VCS.

This clearly is a bug. The package is faulty in is description of optdepends. The current description for git, mercurial, etc is wrong. There is no preference involved here.

Daniel, that is true, that might work. I find it just marginally useful, though.

I think just either a list of optdepends without any description, or a more descriptive text of when and how the optional dependencies are actually used would be far more useful.

Allan, you are wrong. There is no basis for saying that this is a bug. We have no documentation anywhere stating that the optdepends description should be anything but "A short description of what each package provides" (from the Arch wiki) and the vague "for informational purposes only" from the PKGBUILD man page (together with a sparse and poorly worded example with no explanation for why the example is supposed to be the epitome of optdepends descriptions).

Arch Wiki: https://wiki.archlinux.org/index.php/PKGBUILD#optdepends
PKGBUILD man page: https://www.archlinux.org/pacman/PKGBUILD.5.html#_options_and_directives

The wiki now states "A short description of the extra functionality each optdepnd provides for the package should also be noted". The PKGBUILD man page will be updated too.

You have three developers here saying you are wrong - one, if not two, of which wrote the optdepends support in pacman. The vast majority of other package provide a decent description for what the optdepend provides for the package. These are all not so subtle hints that your are wrong.

If you can not manage simple tasks in packaging, we will need to deal with this further.

Allan, I only see two "devs" saying I am wrong here: you and Dave. That you have written the optdepends support in pacman is irrelevant. This isn't about development, but policy and proper documentation (which was lacking).

To imply that I can not manage simple tasks in packaging is insulting and baseless. It seems to me that someone can not manage simple tasks in documentation, policy-making and project management.

Updated the optdepends descriptions in the go package. Can this issue now finally be closed without being reopened?

We don't have an explicit policy to bump pkgrel by one when rebuilding and reset it to one on an update either. But everyone manages that. We generally assume that Arch packages are not stupid and can use common sense, but we can dumb it down in future.

Anyway, updated optdepends are acceptable to me.

Sure, if you want to believe that every viewpoint not held by yourself (or preferred method of working) is "dumb" or "stupid", that's your call. I find it a bit naive, but if you can patronize while at the same time writing better documentation, at least it has a purpose.

I'm happy that the optdepends issue is finally settled.