[arch-general] depends vs. optdepends

[Troy Engel]

On Mon, Dec 29, 2014 at 6:13 PM, Doug Newgard <scimmia at archlinux.info> wrote:
> You found 4 binaries, how many more would you have found if you didn't
> coincidently happen to have the optional deps for them already
> installed?

If I found more, I would report them - just as I did these four. Using
a logical fallacy of false equivalence won't win this particular
point, just because I didn't find every last one does not denote it
isn't an issue to be discussed. By finding the four I did, I
contribute towards chipping away at problems and try making Arch
better tomorrow that it is today.

> Then add in all of the number of python and perl scripts
> that are broken/would be broken without the optional deps. It's
> actually very, very ubiquitous in Arch and is the entire point of
> optional dependencies.

I agree on anything scripted - again you're trying to use false
equivalence logic as I *specifically* called out that they were
executable/binary files, not interpreted scripts of some sort. I
presented two conflicting sources of what 'optdepends' means, there
was no comment about why they're different descriptions. I have
packaged python/perl/bash/ruby/etc. scripts and understand the
pitfalls of these, this isn't what was presented for discussion.

> If it's not required for the major functionality
> of the package and the software functions without it, it's optional.

The lm_sensors package provides the daemon sensorsd (complete with
systemd unit). To use this very specific example, are you declaring
that this included binary is not "major" and you *cannot* launch this
daemon as-is but that's not considered non-functional. What is your
definition of "the software functions" if every binary included in the
package does not at least launch?

> This isn't setting a new precedent, this has been SOP for a long time.

So that makes it correct? "This is the way we've always done it" --
we'd never have systemd as an example if things were not open to
discussion and change.

> Arch isn't Debian, every binary isn't given it's own package.

Nor did I ever claim it was (and what are you even arguing here?) -- I
was careful to mention the packaging tools (RPM/DEB) as both of these
infrastructures underpin many distros. In both of these systems there
is automatic library dependency tracking/inclusion as part of the
process; if a binary is in a package and has a shared library
dependency, it's implicitly pulled in as a need to install (if not
explicitly defined). As far as I am able to tell, Pacman has no such
capability so everything must be done manually.

-te