Re: Sectionning overhaul (Was: Getting rid of section "base" ?)

[Yann Dirson <ydirson@altern.org>]

James Deikun writes:
 > It seems like we have many of the same ideas...?

Seems so :)

 >  But I'm not sure your
 > current scheme would be as good for packages with multiple interfaces.

Well, just use the "," separator and you're done - or is there
something I missed ?

 >  Of
 > course, there are many things that seem intriguing about it too... I'll
 > have to look up the beginning of the thread on the archive though before I
 > can say much more than that.

I summarized and developped at
http://www.altern.org/ydirson/en/software/data-oriented.html

 >   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 seems at 1st glance to be better provided using an Enhances
field.


 >   2) Exclude (hide) all -dev libraries etc.
[...]
 >   3) Exclude (hide) as above all runtime only libraries.

...and these would greatly be helped by the "Nature" tag we talked
about (proposed values of "Nature" being things like "application",
"library", "development kit", "documentation" and the like).

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

Those would surely appear providing a common virtual package, and the
existing Depends field could IMHO be used for this special case.

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

Yep.

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

Yes.  That really seems related to the model I propose at
http://www.altern.org/ydirson/en/software/data-oriented.html

I just added a "programming interfaces" section to this newborn page.
It is surely necessary to add to it.  Your comments are welcomed.

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

Yes, it is possible that the Enhances field would be rendered useless
by this feature, but only if the to-be-enhanced packages declare the
relevant interfaces - this is really a drawback, although for now I
don't give it too much weight.

Regards,
-- 
Yann Dirson    <ydirson@altern.org> |    Why make M$-Bill richer & richer ?
debian-email:   <dirson@debian.org> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://www.altern.org/ydirson/      | Check <http://www.debian.org/>