Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[James Deikun <james@netcsi.com>]

>Consider, all ther perl libraries could 'enhance' perl, so it would be
>possible to generate a list of all the perl libraries. All C -dev packages
>could enhance gcc, python libraries python, etc, etc.

As a software developer and user of Debian (but not currently a Debian
developer) I've been thinking for a while about the problem of finding perl
libraries, python libraries, etc. for various purposes.  There are several
things I'd like to be able to do in that regard:

  1) Find all the libraries, for a given language or set of languages, that
provide interfaces to a given underlying program, protocol, or library.
(This could also be extended to find x interfaces, clis, gnome or kde
interfaces, and so forth, in which case it would be useful for
nondevelopers as well.)  Good options for quickly specifying a 'given set'
of language environments could include:  all the languages the user has
indicated a desire to have development tools for (or all the UIs e has
installed the basic support for), all the languages/interfaces the user has
not indicated (somehow) a specific disdain for, all the
languages/interfaces (pick one) period, and of course, one specific chosen
language, which is the most helpful when trying to add features to existing
code.

     Shell scripting interfaces to things, btw, are for the most part the
same as clis...

  2) Exclude (hide) all -dev libraries etc. that are exclusively for
languages/environments I choose not to use.  For some people that might
include  python, for others ada, yet others common lisp... (maybe
console-apt can do this already via dependencies?  but that's sloppy ... it
could hide things one doesn't mean to hide ...).  Packages like this would
only be shown or installed if they came up as dependencies of other
packages the user has chosen.

  3) Exclude (hide) as above all runtime only libraries.  While it would be
useful for advanced users to be able to inspect the whole set of possible
libraries in some cases (such as debugging shared lib weirdness in
unstable, or installing alien packages), for normal package selection use
they only get in the way.  After all, unless you ARE installing non-debian
binary packages you would never really need to install runtime libraries
without either a -dev library or a package that depended on it.

     (Oops, I just thought of a case where you COULD want to install a
library without changing anything else ... the case of libraries that
provide alternate implementations of an ABI, such as the various OpenGL
libraries.  Maybe all library packages that COULD satisfy a dependency of
an installed package should be unhidden, even if they aren't currently
installed.)

I feel that others would probably find these kinds of features useful as well.

I don't think 'Enhances:' could be extended in any straightforward way to
support these sorts of operations, especially in the presence of all the
various 'omnibus' packages in debian.  (Sure, a few very famous ones have
been broken up for slink and potato, but imho if one got rid of ALL
packages of this type the package system would become too fine-grained to
be manageable even with the help of apt...)

It seems to me that the best approach to implementing the sort of things I
described above is to treat each package as containing several arcs in a
directed graph connecting programs, protocols, languages, uis, libraries,
and services.  These arcs would be described in a new field in the control
file, perhaps, 'Provides-Interfaces:'.  There would be a necessity to
distinguish between providers of source-level interfaces and runtime
interfaces (some packages, like perl modules, provide both inseparably).
This could be brought about either by having two flavors of endpoints
(which complicates specifying the 'lower' end of the arc, that is, the
thing you want to access FROM the 'upper' end), or by having two flavors of
arcs; i'm not sure which would be better overall.

It's probably a waste of time to try to use 'Enhances:', specified like a
traditional dependency field but with reversed sense, to try and support
these kind of smart viewing and selection features because it glosses over
information like the direction of interfaces and exactly what can interface
to what through a package containing interfaces to and from a lot of
things.  And of course there's zero chance of seeing them in potato :).
Maybe +1 or +2?

I apologize if this message isn't appropriate for debian-policy.


--
James Deikun, Techie(tm), CSI Multimedia
The opinions expressed &c.