On Mon, Dec 29, 2014 at 6:13 PM, Doug Newgard <scimmia@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