On May 20, 2010, at 5:03 AM, Dominique Dumont wrote:
> On Thursday 20 May 2010 10:03:55 Denis Washington wrote:
>> How does that sound?
>
> A bit like some ideas I have regarding packaging for ISV ;-) :
>
> http://wiki.debian.org/SummerOfCode2010/UniversalPackageForIsv
>
> I proposed this for Google Summer of code, but no student stepped up.
> These ideas are not well fleshed out, and I don't have time to work on them
> until probably 2011 (I'm mentoring another project regarding package config
> upgrade).
>
Well if/when you get to this
Dependency are not declared with native package names, but with
functionality names (a bit like the generic names used by update-alternatives).
poke me.
Here's some historical context re "functionality names" and "translation"
from RPM <-> LSB:
LSB insists
No dependencies except "Requires: LSB" are permitted.
and RPM (and most package managers) rely on dependency assertions
to assemble collections of packages to be installed reliably.
So in order to have it both ways, @rpm5.org has carefully
moved most of the automated dependency generation from static to install-time
methods. I.e. the dependencies can be generated automatically from content
while installing, not from explicit static markup contained
in packages while building.
The connection with your proposal is that a naming/namespace taxonomy
based on "functionality" (e.g soname(LIBRARY) for ELF linkage as
one easy to describe "functionality") is very much needed.
Note that (imho) "functionality" needs to be objectively tied to
some testable closure mechanism, not left to some mysterious and magical
or implicit DWIM for package dependency assertions as in update-alternatives.
Nothing wrong with update-alternatives "functional" names per se, just that
the closure mechanism needs to be well defined too, such as whether DT_NEEDED
is matched with a DT_SONAME for ELF linkage.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
