[arch-general] depends vs. optdepends

[Doug Newgard]

On Mon, 29 Dec 2014 18:39:55 -0600
Troy Engel <troyengel+arch at gmail.com> wrote:

> 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.

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