On Mon, 29 Dec 2014 18:39:55 -0600 Troy Engel <troyengel+arch@gmail.com> wrote:
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.
No false equivalence here. My point is there are likely many, many more binaries on your system that have the same issue, you just happen to already have the optional deps installed. That equivalence is not false.
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.
Why are you trying to separate compiled binaries and interpreted scripts? There's no functional difference in respect to this 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 is up to the judgment of the individual packager.
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.
I was responding to your claim of setting "a dangerous precedent", where that precedent was set long ago. You need to realize that you aren't talking about a bug in one or two packagers' packages, you're talking about the packaging consensus that Arch has used for a long time.
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
Yes, pacman is a much simpler package manager, but that has nothing to do with Arch's packaging practices in this case. Arch will generally keep a package together as shipped by upstream unless there's a very compelling reason to split it up. Debian is the other extreme where they split just about everything into it's own package. Simply different philosophies. Doug