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