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