Bug#934948: Unnecessary dependencies vs multiple binary packages

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Hi, Simon.  Thanks for the writeup which makes things much more
comprehensible.

Simon McVittie writes ("Bug#934948: Unnecessary dependencies vs multiple binary packages"):
> * All correctly-packaged Ruby libraries have a dependency on the Ruby
>   interpreter, regardless of whether they also contain a #!/usr/bin/ruby
>   executable script. This is similar to what is done for Perl and Python.
>   - Please fact-check: is this true?

I think the reason we do this for Python might be related to Python
interpreter version compatibility.  Otherwise it doesn't seem like it
serves any purpose ?

For Perl, the actual interpreter package is perl-base.  There are Perl
scripts which run with perl-base and without perl-modules.  "perl" is
most a metapackage - its main purpose is to pull in perl-modules.  It
is true that pure-Perl modules depend on perl-base, directly or
indirectly.  When the dependency is on "perl", that pulls in
perl-modules: ie, it isn't just the interpreter.  I think the primary
purpose of the dependency on perl-base (where that is what is used) is
to specify the minimum perl version.

Would anything go wrong (with Perl or Python, say) if we didn't depend
on the interpreter ?  (Assuming the dependency being dropped is
unversioned.)

I am the maintainer of a Tcl extension ("chiark-tcl") which does not
Depend on any Tcl interpreter, even though there obviously needs to be
one for it to be any use.  A package which uses this extension (eg
"sauce") Depends on the interpreter.

> Design principles
> =================
> 
> (These are principles, not hard rules, so we might need to compromise on
> some of them where they conflict.)
...
> * When an executable is installed, it must work.
>   - That is, its dependencies must be sufficient.
>   - Exception: if it's in /usr/share/doc/*/examples it doesn't have to work.
> 
> * When a library is installed, it must be usable in the relevant
>   interpreter(s).
>   - That is, its dependencies, plus the interpreter itself, must be
>     sufficient to import and use the library.

We have compromised on these principles on many past occasions.  The
archive is full of portmanteau packages, which contain a variety of
things with different practical dependencies.  We often write
Recommends or Suggests for the practical dependencies of less-critical
subcomponents.

devscripts is perhaps the best example.

> * When a user installs a library for one interpreter or environment,
>   in general, we don't want the package dependencies to require that
>   user to install an unrelated interpreter.

I think this design principle should generally outweigh the previous
two.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.